List of Archived Posts

2007 Newsgroup Postings (04/23 - 05/02)

John W. Backus, 82, Fortran developer, dies
Linux: The Completely Fair Scheduler
Linux: The Completely Fair Scheduler
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
Laugh, laugh. I thought I'd die - application crashes
John W. Backus, 82, Fortran developer, dies
U.S. Cedes Top Spot in Global IT Competitiveness
when was MMU virtualization first considered practical?
when was MMU virtualization first considered practical?
when was MMU virtualization first considered practical?
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
Does anyone know of a documented case of VM being penetrated by hackers?
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
Latest Principles of Operation
Latest Principles of Operation
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
Does anyone know of a documented case of VM being penetrated by hackers?
John W. Backus, 82, Fortran developer, dies
Latest Principles of Operation
ANN: Microsoft goes Open Source
Internal DASD Pathing
Internal DASD Pathing
ANN: Microsoft goes Open Source
John W. Backus, 82, Fortran developer, dies
Internal DASD Pathing
John W. Backus, 82, Fortran developer, dies (Actually, Working under the table!)
Does anyone know of a documented case of VM being penetrated by hackers?
Best practices for software delivery
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
Latest Principles of Operation
latest Principles of Operation
IBM System/360 Model 85: The Bashful Computer
Linux: The Completely Fair Scheduler
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
public key password authentication
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
A tribute to Jim Gray
How the Internet took over
illegal aliens
Free Checking
Free Checking
public key password authentication
public key password authentication
Free Checking
John W. Backus, 82, Fortran developer, dies
Sizing CPU
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
John W. Backus, 82, Fortran developer, dies
illegal aliens
Interrupts
Disc Drives

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 06:50:28 -0600
jmfbahciv writes:
It seems that the banking industry wants to push the computing work, especially the mainframe part of it, off onto each individual. That's what removing paper checks is all about. IMO, they are pushing this computing work in exactly the wrong direction.

re:
https://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies

check21 is more about the physical transport of checks ... and issues related to not clearing until physical paper moved.

old folklore is that fed-ex got its start moving paper checks overnight ... large fleet of planes from all over the country with large loads of paper checks arrive in nashville late at night ... the bags of paper checks are run thru huge farms of check sorters ... put into other bags, rushed out to the planes which turn around and return.

past posts about check sorters
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2002.html#18 Infiniband's impact was Re: Intel's 64-bit strategy
https://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
https://www.garlic.com/~lynn/2006m.html#1 Large Computer Rescue
https://www.garlic.com/~lynn/2007e.html#28 Securing financial transactions a high priority for 2007

somebody once told me a similar, but different story about long ago, and far away, at warehouses all over the country ... where late at night a bunch of armored trucks pull into the bldg ... and all back up ... sort-of forming a "wagon circle" (with no gaps) ... and then the back doors open onto the circle ... and they all exchange bags of paper checks ... for each others (local) financial institution.

Linux: The Completely Fair Scheduler

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux: The Completely Fair Scheduler
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 07:22:07 -0600
jmfbahciv writes:
Do you get just a little bit discouraged? I sure do.

re:
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler

you mean, as opposed to
https://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer

or the nsfnet stuff?
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
https://www.garlic.com/~lynn/subnetwork.html#nsfnet
and
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

or the ha/medusa stuff?
https://www.garlic.com/~lynn/lhwemail.html#medusa
and
https://www.garlic.com/~lynn/2006x.html#3

Linux: The Completely Fair Scheduler

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux: The Completely Fair Scheduler
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 07:36:47 -0600
jmfbahciv writes:
Do you get just a little bit discouraged? I sure do.

re:
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler

then, of course, there is Boyd's line ...
https://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 10:03:26 -0600
krw <krw@att.bizzzz> writes:
The problem with the F16 is its single engine. The local ANG group was tasked with air intercept (mostly Soviet Bears) over the North Atlantic and NE Canada/US. The pilots were a little nervous out over the N-Atlantic without a spare candle. They were going to get F15s but were retasked to air-to-mud instead. After 9/11 they still do intercept though.

re:
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies

part of the issue is that F16 can significantly outperform F15 in most scenarios ... is significantly cheaper ... or have a lot more of them flying for the same cost ... not only in terms of planes for dollar ... but there is also a significant issue of the ratio of service/downtime hrs per flying hrs.

In the previous references (in this subthread), there were also some similar comments about the F18 in relationship to the F14 ... significant more planes per dollar cost ... and more flying hrs per service (downtime) hrs.

Then there was an attempt with the F20/tigershark ... to carry it to a whole new level ... in terms of planes per dollar, flying hrs per service/downtime hrs, as well as skill levels and parts to keep it flying (while sacrificing as little as possible vis-a-vis F16)

past posts mentioning f20/tigershark
https://www.garlic.com/~lynn/2002c.html#14 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2005d.html#45 Thou shalt have no other gods before the ANSI C standard

of course, none of this matters if you have an infinite amount of money, an infinite number of planes, an infinite number of pilots, and an infinite number of service people with an infinite amount of training and spare parts.

other posts in the thread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies

past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 13:03:37 -0600
kkt <kkt@zipcon.net> writes:
How frequently does the single engine flame out in a situation where a second engine would save you? How likely is that compared to all the other ways you can die flying a fighter, such as being out-dogfought by a more maneuverable, single-engine fighter?

f16 was vastly superior fighter ... touted for the f15 was that it could be sort of be dual-use ... half-way a fighter and half-way a bomber ... or it could act as a missile platfrom, stand-off from the actual battle and lob missiles at the other guy.

part of the problem was that the f15 wasn't really good at either ... as well as being extrodinarily expensive both to purchase and to maintain.

reference to f15 being retargeted as fighter/bomber from its original role justified as multi-role fighter
http://www.aerospaceweb.org/aircraft/bomber/f15e/

above has F15 estimated cost at $43m

and f16
http://www.aerospaceweb.org/aircraft/fighter/f16/

above has F16 est. cost at $14m-$18m (can get three F16s for every F15) ... and comment "considered by many to be today's best all-round figher".

While Boyd significantly improved the F15 (from its starting design) ... he was able to start from scratch with F16.

previous posts
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies

this has much more detailed discussion about driving factors that produced F16 (most of them from Boyd)
http://www.fas.org/man/dod-101/sys/ac/f-16.htm

from above (some reference to engine failure)
Northrop argued that its twin-engine design added an essential safety factor, citing its experience with the small twin-engine F-5 fighter as an example. USAF did not find this persuasive, in part because a two engine plane with one engine out is useless in combat, and the probability of an engine failure was nominally twice as high with two engines as with one. The higher performance, better transient maneuverability, longer range, and lower cost of the YF-16 carried the day, and in 1976 the F-16 was chosen over the F-17.

USAF was then in the uncomfortable position of having a lightweight fighter design that could outmaneuver and outrange its pride and joy, the F-15 air superiority fighter. In real-world combat conditions, which meant Mach 1.2 or below, the F-16s held a significant edge over the F-15. To some extent this problem was solved by designating the F-16 as a "swing fighter" to do both air-to-air and air-to-ground, while the F-15 was to continue its aristocratic mission of pure air-to-air.


... snip ...

the above also goes into some of the design/implementation creap that settled into F16 which might be taken as justification behind the attempt to do a reset with the F20/tigershark
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies

other posts in this subthread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies

previous post with attempt to put some computer bent back into the thread ... since much of boyd's work was based on complex (computer aided) mathematical calculations
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies

this reference that discusses something more of Boyd's biographical details
http://www.sci.fi/~fta/JohnBoyd.htm

does mention that in the middle of doing all this design stuff for F16 ... he got tasked to spend a year in Thailand running the computing center at "spook base". This was possibly one of the largest datacenters in the world at the time ... since other biographies make mention that it represented a $2.5b windfall for IBM. A few past posts mentioning spook base:
https://www.garlic.com/~lynn/2005t.html#1 Dangerous Hardware
https://www.garlic.com/~lynn/2005t.html#2 Dangerous Hardware
https://www.garlic.com/~lynn/2005t.html#5 Dangerous Hardware
https://www.garlic.com/~lynn/2006u.html#51 Where can you get a Minor in Mainframe?
https://www.garlic.com/~lynn/2007g.html#13 The Perfect Computer - 36 bits?

past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 13:31:40 -0600
krw <krw@att.bizzzz> writes:
The FA18 didn't sacrifice the second engine though. The Navy wouldn't have stood still for that.

re:
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies

as previous posts about mentioning LWF and Boyd running the program in the pentagon ... he improved the F15 and then did F16 and lot of the stuff for F18. The issue between the F15 and F16 wasn't just about whether it was one engine or two ... it was what was the mission and you then could throw out everything not needed for the mission (both the F16 compared to the F15 and the F18 compared to the F14).
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies

so you should be taking what was the mission profile for the F15/F16 and what did Boyd do ... versus mission profile for the F14/F18 and what did Boyd do.

other posts in this subthread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies

somewhat related is past post about KISS and simple can actually be more difficult ... but quite a bit more effective ... than complex
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits
https://www.garlic.com/~lynn/2007h.html#30 sizeof() was: The Perfect Computer - 36 bits

I claimed something similar designing a hardware authentication token, ... somewhat facetiously claiming in the mid-90s that I was going to take a $500 mil-spec part, aggresively cost reduce it by nearly three orders of magnitude and at the same time making it more secure ... for some topic drift ... past posts:
https://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
https://www.garlic.com/~lynn/aadsm15.htm#6 x9.59
https://www.garlic.com/~lynn/aadsm21.htm#11 Payment Tokens
https://www.garlic.com/~lynn/aadsm21.htm#26 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
https://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#32 AMD to leave x86 behind?

some if it shows up here
https://www.garlic.com/~lynn/x959.html#aads
and in these patents (which we have no rights/interest)
https://www.garlic.com/~lynn/aadssummary.htm

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 13:47:07 -0600
krw <krw@att.bizzzz> writes:
Reset? The Tigershark was a bet my NA completely on their dime. The DOD didn't ask for it. Since it wasn't their idea they "disavowed all knowledge of its actions".

significant factions in DOD attempted to keep Boyd from doing F16 ... as per prior reference ... as per reference in this post to Leavenworth
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies

... and then where was Boyd spending some amount of his time when F20/Tigershark was being done? I've claimed it was his attempt to reset back to the original F16 design ... before all the design/implementation creep mentioned in
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
and
http://www.fas.org/man/dod-101/sys/ac/f-16.htm

started to show up.

Boyd had significant battles both inside and outside the gov. to pull off the F16 ... and I've claimed that he was involved in attempting to pull off something similar with F20/tigershark (being closer to his original f16 design).

other posts in this subthread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies

past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 14:24:08 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
somewhat related is past post about KISS and simple can actually be more difficult ... but quite a bit more effective ... than complex
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits
https://www.garlic.com/~lynn/2007h.html#30 sizeof() was: The Perfect Computer - 36 bits


re:
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies

and reference here

The US Combat Aircraft Industry, 1909-2000, Structure, Competition, Innovation
http://www.rand.org/pubs/monograph_reports/2005/MR1696.pdf

one of the footnotes in above:
However, Boyd and most of the rest of the Fighter Mafia did not accept the assumption that lighter and simpler meant less capable. They argued that complicated, expensive modern fighters did not work well in real combat situations and had poor reliability and maintenance records. Larger numbers of simpler, more agile, more robust, and more reliable fighters, they argued, would actually provde greater overall combat capability for the total force structure.

... snip ...

While Boyd was responsible for the original F16 ... as it got more complicated and more expensive ... it sacrificed some number of the original objectives. I've repeatedly claimed that F20/Tigershark was an attempt to return to those original objectives.

One of the "colorful" tales about F20/Tigershark not actually making it into the market ... was that with its significantly lower price and significantly less complex ... it would be ideal for countries outside the US. However, supposedly there was a very strong lobby in Congress that provided foreign aid for such countries (which was the source of money used to buy such material) ... and the lobby got language written in that the AID money had to be used for F16s (and couldn't be used for the much less expensive and less complex F20/Tigershark).

past post mentioning that Boyd's versions/stories could be much more colorful
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies

past posts mentioning F20/tigershark
https://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive ... long posting warning
https://www.garlic.com/~lynn/2002c.html#14 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2005d.html#45 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2006g.html#13 News Release
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies

other posts in this subthread:
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#70 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies

past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 15:35:52 -0600
CBFalconer <cbfalconer@yahoo.com> writes:
This post shows your newsreader failure to keep the reference count down to 20 items.

the reference URL approach can be simpler than have a 500+ line post that except for a few lines ... is all the previous posts in the thread for possibly the last several weeks :)

recent posts happening to mention Boyd, swing-wing, F14, F15, F16, F18, and/or F20/Tigershark
https://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista
https://www.garlic.com/~lynn/2007b.html#37 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007c.html#25 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#18 Is computer history taught now?
https://www.garlic.com/~lynn/2007e.html#45 time spent/day on a computer
https://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
https://www.garlic.com/~lynn/2007e.html#53 time spent/day on a computer
https://www.garlic.com/~lynn/2007e.html#55 time spent/day on a computer
https://www.garlic.com/~lynn/2007f.html#15 Designing database tables for performance?
https://www.garlic.com/~lynn/2007f.html#23 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#29 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#41 time spent/day on a computer
https://www.garlic.com/~lynn/2007g.html#13 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#57 ANN: Microsoft goes Open Source
https://www.garlic.com/~lynn/2007h.html#68 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#69 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#71 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#72 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#73 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#75 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 21:41:19 -0600
jmfbahciv writes:
It seems that the banking industry wants to push the computing work, especially the mainframe part of it, off onto each individual. That's what removing paper checks is all about. IMO, they are pushing this computing work in exactly the wrong direction.

re:
https://www.garlic.com/~lynn/2007i.html#0 John W. Backus, 82, Fortran developer, dies

more than anybody possibly ever wants to know about check21

Fed Reports to Congress on Check 21 Progress
http://www.federalreserve.gov/boarddocs/RptCongress/check21/check21.pdf

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2007 21:57:39 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
The US Combat Aircraft Industry, 1909-2000, Structure, Competition, Innovation
http://www.rand.org/pubs/monograph_reports/2005/MR1696.pdf

one of the footnotes in above:

However, Boyd and most of the rest of the Fighter Mafia did not accept the assumption that lighter and simpler meant less capable. They argued that complicated, expensive modern fighters did not work well in real combat situations and had poor reliability and maintenance records. Larger numbers of simpler, more agile, more robust, and more reliable fighters, they argued, would actually provde greater overall combat capability for the total force structure.

... snip ...


re:
https://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies

F-20 --- The Tigershark Survivors
http://www.johnweeks.com/f20/index.html

from the above:
In the end, the F-20 Tigershark was reported to use 53% less fuel, required 52% less maintenance, had 63% lower operating costs, was four times more reliable, and had the fastest scramble time of any fighter jet in the world. That made it the finest fighter aircraft that never went into production.

... snip ...

F20 Frequently Asked Questions
http://www.f20a.com/f20faq.htm

from above:
Working on the F-20 was one of the great experiences in the life of many participants. The lack of the usual government bureaucracy, the co-operative relationship between the company and its co-investing suppliers, the espirit-de-corps, the belief that they were creating an insanely great aircraft - all of this made the workers 'true believers'. Perhaps it can only be compared to the Apollo program or missile programs of the late 1950's in the intensity of the team development experience.

... snip ...

A case study of the F-20 Tigershark
http://www.rand.org/pubs/papers/P7495/

Laugh, laugh. I thought I'd die - application crashes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Laugh, laugh. I thought I'd die - application crashes
Newsgroups: bit.listserv.ibm-main,alt.folklore.comupters
Date: Mon, 23 Apr 2007 22:34:29 -0600
oscarptyltd@ibm-main.lst (Clem Clarke) writes:
In PCP, MFT and MVT, SVC 99 didn't even exist! Nor TSO.

just for laughs here is the (Hercules) build install procedure for TSO/TCAM for MVT
http://www.conmicro.cx/hercos360/tsotcam.html

and from my rfc index
https://www.garlic.com/~lynn/rfcietff.htm

RFC90
https://www.garlic.com/~lynn/rfcidx0.htm#90

90
CCN as a network service center, Braden R., 1971/01/15 (6pp) (.txt=11929)

...

about UCLA 360/91 running MVT, URSA, a "conversational remote job entry system" and TSO

from the RFC:


d) TSO  IBM's new general purpose time-sharing subsystem
under MVT, to be available at CCS sometime during
        1971. TSO supports 2741's and Teletypes (and at
CCN it will support CCI consoles). TSO is
reminiscent of CTSS in its capabilities and
command language.

... snip ...

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 24 Apr 2007 07:58:33 -0600
jmfbahciv writes:
That's a minor detail. I am thinking about having any ability to detect that the fit has hit the shan before a bank goes bust.

re:
https://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies

this long-winded post includes disussion of effects of variable rate mortgages nearly taking down a leading financial institution
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

U.S. Cedes Top Spot in Global IT Competitiveness

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: U.S. Cedes Top Spot in Global IT Competitiveness
Newsgroups: alt.folklore.computers
Date: Tue, 24 Apr 2007 09:24:09 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:

https://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2006m.html#49 The Pankian Metaphor (redux)
https://www.garlic.com/~lynn/2006x.html#32 Toyota set to lift crown from GM

latest update ... somewhat going back to the whole thing about import quotas from a couple decades ago (supposedly temporary measure to allow the industry breathing room to remake themselves)

Toyota's March Sales Jump, GM, Ford Fall
http://www.redorbit.com/news/business/891452/toyotas_march_sales_jump_gm_ford_fall/index.html

as well as topic drift about the C4 activity
https://www.garlic.com/~lynn/2007g.html#29 The Perfect Computer - 36 bits?


re:
https://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT Competitiveness

Toyota Tops GM in 1Q Global Auto Sales
http://biz.yahoo.com/ap/070424/japan_toyota_gm.html?.v=22

when was MMU virtualization first considered practical?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: when was MMU virtualization first considered practical?
Newsgroups: alt.folklore.computers
Date: Tue, 24 Apr 2007 17:39:16 -0600
Ben Pfaff <blp@cs.stanford.edu> writes:
All of that is just background for my question, although I'll gladly accept corrections to any of it. My question is this: in my earlier research, I was sure that I found a reference that said that, at approximately the time when CP-40 and CP-67 were being developed, developers considered it impractical or even impossible to virtualize an MMU (at least with any efficiency). The CP-40 extension and CP-67 certainly proved them wrong. But now I'm unable to find any trace of that reference. Can anyone point me in the right direction?

waiting for 360/67 ... the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

tried to get 360/50 to modify with hardware blaauw box ... however it seems that all the spare 360/50s was going to FAA ATC system project ... so they had to settle for a 360/40 to modify ... on which cp40 was implementated (aka 65-66). My recollection of the 360/40 relocation hardware is hazy, it didn't have associative array (hardware tlb) ala the 360/67 ... the 360/40 had 256kbytes of real memory, 64 4k pages ... and there was some sort of hardware register associated with each real 4k page ... which gave the virtual page number translation (possibly implemented somewhat like the 360 storage protection key array?)

from melinda's history
https://www.leeandmelindavarian.com/Melinda#VMHist
Comeau has written: Virtual memory on the 360/40 was achieved by placing a 64-word associative array between the CPU address generation circuits and the memory addressing logic. The array was activated via mode-switch logic in the PSW and was turned off whenever a hardware interrupt occurred. The 64 words were designed to give us a relocate mechanism for each 4K bytes of our 256K-byte memory. Relocation was achieved by loading a user number into the search argument register of the associative array, turning on relocate mode, and presenting a CPU address. The match with user number and address would result in a word selected in the associative array. The position of the word (0-63) would yield the high-order 6 bits of a memory address. Because of a rather loose cycle time, this was accomplished on the 360/40 with no degradation of the overall memory cycle

when the science center was able to finally get 360/67 .. they ported cp40 to 360/67 renaming it cp67 (aka 66-67). details of 360/67 virtual memory hardware can be found in functional spec
http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A27-2719-0_360-67_funcChar.pdf

initially it supported vanilla 360s (w/o virtualized virtual memory) ... not so much because it was impossible ... but it was a lot more code. Around '69 ... somebody on assignment to the cambridge science center from France ... did the additional implementation to provide virtual 360/67s virtual machines ... allowing cp67 to run in a 360/67 virtual machine (i.e. cp67 running under cp67).

later the same person (still on assignment) did much of the enhancements to implement 370 virtual memory as option ... i.e. ability to select the virtual machine for 370 (with 370 virtual memory architecture specirication) ... with cp67 providing the simulation according to the 370 hardware architecture (as optional alternative to simulating according to 360 hardware architecture specification). then a special modified version of the cp67 kernel was created to run on 370 hardware architecture (as opposed to 360/67 hardware architecture).

later the same person shows up back in France responsible for EARN ... some old (EARN related) email correspondence
https://www.garlic.com/~lynn/2001h.html#65 UUCP email
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006w.html#43 IBM sues maker of Intel-based Mainframe clones

some old posts about 370 virtual machine support (including 370 hardware virtual memory) was up and running in cp67 a year before the first engineering 370 processor with virtual memory was operational (and the special 370 flavor of the cp67 kernel was used as test of the hardware correctness)
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
https://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
https://www.garlic.com/~lynn/2006q.html#45 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007f.html#12 FBA rant

when was MMU virtualization first considered practical?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: when was MMU virtualization first considered practical?
Newsgroups: alt.folklore.computers
Date: Tue, 24 Apr 2007 22:19:22 -0600
Ben Pfaff <blp@cs.stanford.edu> writes:
It's interesting that this would be someone from France who implemented it. This rings a bell: I have a paper here titled 'Virtual Machine or Virtual Operating System?' attributed to J. Bellino, Cl. Hans from IBM-France, Grenoble Scientific Center. Is either of these people relevant?

re:
https://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?

claude also did assignments in the states ... but it was neither of the authors you mention.

when was MMU virtualization first considered practical?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: when was MMU virtualization first considered practical?
Newsgroups: alt.folklore.computers
Date: Tue, 24 Apr 2007 22:31:24 -0600
Ben Pfaff <blp@cs.stanford.edu> writes:
The System/370 relocation architecture was different from the 360/67 architecture; it allowed both 2K and 4K pages and both 64K and 1M segments. So, Auroux modified his modified CP-67 to support 64K segments and the new System/370 instructions. He ran that system second-level, so he could run a virtual S/370 third-level. He developed a prototype "CP-370" in that third-level virtual machine. Then, to test this CP-370's virtualization of System/370 virtual memory, he had to run it both third- and fourth-level, with a couple of CMS machines running fifth-level.

Alan was his first name.

Part of the issue was that virtual memory for 370 hadn't been announced yet ... so was a carefully guarded corporate secret. the science center also provided online access to various people from univ. and colleges in the boston area ... so there was some security issues regarding what the non-employees saw on the cambridge system.

the first level cp67 system running on 360/67 didn't have any of Alan's virtual 370 modifications ... those modifications were part of a separate cp67 kernel running in a 360/67 virtual machine (and outside of the prying eyes of non-employees). It was this virtual cp67 kernel ... which provided the 370 virtual machines. Then a cp67 kernel with more extensive modifications ... making it able to run on a (real) 370 with virtual memory support (rather than a 360/67 with virtual memory support) would run in one of those 370 virtual machines. From various posts referenced in the previous post
https://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?


360/67 real hardware
running cp67l kernel ... providing standard 360 & 360/67 virtual machines
running cp67h kernel ... in 360/67 virtual machine providing 370
   running cp67i kernel ... in 370 virtual machine
running cms in 370 virtual machine

when 370 engineering models initially became available with virtual memory hardware ... it was common to find cp67i kernels running on them.

then a couple people from san jose came out and added block multiplexor channel, 3330 disk and 2305 device support to the cp67i kernel ... this cp67i kernel with new 370 device support (rather than 370s running with the older 2314 disk devices) was frequently referred to as the cp67sj kernel.

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 02:53:05 -0600
Steve O'Hara-Smith <steveo@eircom.net> writes:
Pull transaction banking is the fundamental design flaw here, the movement of money out of an account should be a push not a pull. A cheque on this side of the pond is good for (at most) one transaction, there is a pull mechanism (called Direct Debit) and each recurrent pull has to be setup explicitly before the payee is allowed to start their regular pull. Personally I hate them and try to avoid them in preference to standing orders where there is no freedom for the payee to specify the amount.

so some amount of the check21 numbers are about cost of paper infrastructure.
https://www.garlic.com/~lynn/2007e.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#0 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#9 John W. Backus, 82, Fortran developer, dies

one of the costs is the actual processing of the paper ... which can easily be more than a dollar (across all parts of the infrastructure). somebody writing ten checks a month ... the infrastructure has to recover on the order of $20bucks (or more) per month from somebody. pure zero sum ... means deducting it directly from the account. other means has been if there is minimum balance ... and no interest is paid ... then the money can be invested, and the interest retained (to cover the costs).

so part of check21 is eliminating all those physical costs. justifications for passing check21 included discussions about improving the national economic competitive operations vis-a-vis countries that had much lower use of physical paper checks.

another part of the transitioning to electronic ... is be able to move to real-time, authorized, authenticated transaction ... basically riding the rails of pin-debit. pin-debit is supposedly two-factor authentication i.e. the magstripe, something you have ... and PIN ... something you know ... from 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor

... normally, multi-factor authentication is considered more secure based on assumption that different factors have different vulnerabilities and/or failure modes; aka PIN (something you know) as countermeasure to lost/stolen card (something you have).

part of the problem is that skimming attacks can capture the information from the magstripe (sufficient to make a counterfeit card) and the PIN in a single operation ... aka a common vulnerability, invalidating the assumption about multi-factor authentication having independent vulnerabilities ... and therefor the assumption about it being more secure.

in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (credit, debit, ach, check, internet, point-of-sale, ... aka ALL). Detailed end-to-end study of lots of exploits and vulnerabilities resulted in x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

where it effectively substitutes a digital signature for a PIN in the transaction ... where the PIN is the same on every transactions and can be skimmed and used in replay attacks (for fraudulent transactions) ... the digital signature is unique for every transaction (and countermeasure to all kinds of replay attacks involving using information from previous transactions)

another kind of costs in the (check and check21) infrastructure is insufficient funds (NF) involving checks or other transactions that aren't done in real-time ... i.e. clearing a day or more later. This is also eliminated in the real-time, x9.59 scenario. The out-and-out fraud version of this is somebody comes into town, opens an account with $1000, and gets all sorts of valid checks and authentication. The person then proceeds to execute $20k in transactions and leaves town. All the transactions, otherwise have valid authentication by the authorized person ... it just is that significantly more value is being extracted from the infrastructure than went in. x9.59 digital signature allows for only the authorized person to perform the transaction ... while the real-time operation is countermeasure to a crooked authorized person from performing fraudulent operations.

Some of this can be seen in the walmart (and other merchants that joined in) successful anti-trust action against the card associations. simple use of search engine can turn up lots of references ... examples:
http://www.classactionrefund.com/VisaInfo.html
http://www.inrevisacheckmastermoneyantitrustlitigation.com/history.php3

the issue involved requirements surrounding accepting "pin-less" debit transactions. part of the issue is that pin-debit goes thru in real-time and has two-factor authentication ... and therefor there is less risk ... and much lower interchange fees charged the merchant (i.e. stronger authentication and less chance of insufficient funds). the pin-less debit turns out, not only uses lower authentication ... but also didn't happen in real time. As a result, there was significantly more opportunity for all kinds of fraud ... and therefor the merchants are charged significantly higher interchange fee (for all such transactions, independent of whether actual fraud was involved)

other things considered by x9a10 was PKI-based digital signature operations that includes appending digital certificates to digitally signed operations. these digital certificates would account for 100-times bloat in payload size and processing for typical payment transaction
https://www.garlic.com/~lynn/subpubkey.html#bloat

this bloat for PKI-based payment operations is so large that there also was some X9 standards activity looking at "compressed" digital certificates for use in payment transactions ... recent reference:
https://www.garlic.com/~lynn/2007h.html#31 sizeof() was: The Perfect Computer - 36 bits?

however, the whole paradigm for PKI, certification authorities, and digital certificates is fundamentally for offline transactions between two strangers that have no prior interaction. the issue in real-time transactions is that the account owner can provide their public key (for verifying digital signatures) at the same time they open an account (in much the same way they currently provide mother's maiden name for authentication). since the individual and the individual's financial institution have prior business relationship (existance of the account), the on-file public key for real-time operations can eliminate the redundant and superfluous 100-times bloat represented by typical proposed PKI-based payment transaction operation (and the prior business relationship invalidates the fundamental premise justifying a PKI-based infrastructure)

this is similar to the catch-22 related to on-file public keys proposed for domain name infrastructure
https://www.garlic.com/~lynn/subpubkey.html#catch22

misc. past posts mentioning some kind of fraud, exploit, vulnerability, threat and/or risk
https://www.garlic.com/~lynn/subintegrity.html#fraud

semi-related recent posts
https://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#26 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#32 sizeof() was: The Perfect Computer - 36 bits?

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 03:53:10 -0600
greymaus writes:
Good post. You seem to know what you are writing about. In the past, when large numbers of Irish people emigrated, it was pointed out that we were going to the expense of rearing these people, educating them to a fair degree, and then sending them off to produce money for the U.S. or other economys.

quick search engine for some actual numbers turns up this report from 2004 based on 2002 census data ... executive summary
http://www.cis.org/articles/2004/fiscalexec.html
full report
http://www.cis.org/articles/2004/fiscal.html

some number of other sites turned up by search engine ... reference the above report (apparently because very few other "studies" actually rely on real data).

so quite a few of the websites seem to wave hands and/or claim biases one way or another ... however, i've found that gao reports tend to be unbiased. so searching again but limiting to .gov turns up detailed analysis in GAO report from 1995
http://www.gao.gov/cgi-bin/getrpt?HEHS-95-133

all possible scenarios in the above show positive net costs (total costs minus economic contribution).

now, all the other reports turned up by search engine for gao.gov ... all appeared to look at single or small number of factors ... as opposed to overall total costs and total economic contriubtion yielding net total costs.

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 09:12:39 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
another kind of costs in the (check and check21) infrastructure is insufficient funds (NF) involving checks or other transactions that aren't done in real-time ... i.e. clearing a day or more later. This is also eliminated in the real-time, x9.59 scenario. The out-and-out fraud version of this is somebody comes into town, opens an account with $1000, and gets all sorts of valid checks and authentication. The person then proceeds to execute $20k in transactions and leaves town. All the transactions, otherwise have valid authentication by the authorized person ... it just is that significantly more value is being extracted from the infrastructure than went in. x9.59 digital signature allows for only the authorized person to perform the transaction ... while the real-time operation is countermeasure to a crooked authorized person from performing fraudulent operations.

re:
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies

not actually knowing the basis ... but this might also account for the recent postings about news articles claiming both approx. ten percent decline in overall identity theft costs and at the same time identity theft is exploding/doubling.
https://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#58 Securing financial transactions a high priority for 2007

say somebody is opening an account using a non-existent person. then when they skip town ... the cost all falls back onto the bank; in fact this referenced news item:

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

in this post
https://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007

does say that the improvement comes from better processing of requests to open new accounts.

the explosion/doubling in identity theft ... specifically involved attacks on existing accounts belonging to other people.

if the financial institution did better job of handling new accounts and/or shifting the related fraud costs off to the merchants ... then the net savings for the financial institution (with regard to that kind of identity theft) might be the basis of claiming an overall net descrease in total identity theft costs when at the same time, identity theft involving fraud attacks against existing consumer accounts is exploding/doubling (i.e. the kind that consumers are seeing).

Does anyone know of a documented case of VM being penetrated by hackers?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Does anyone know of a documented case of VM being penetrated by hackers?
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 25 Apr 2007 10:02:21 -0600
rschuh wrote:
Does anyone know of a documented case of VM being penetrated by hackers?

long ago, I briefly succumbed once.

The future system project was in full swing ... lots of past posts
https://www.garlic.com/~lynn/submain.html#futuresys

all the documentation was supposed to be super secret and required need-to-know ... and so it was all being done as softcopy under vm370. they had instituted all sorts of additional security processes.

I had been somewhat panning FS project by comparing what they were doing to a cult film that had been playing continuously for several yrs down in central sq (and making references to the inmates being in charge of the institution).

Anyway ... somebody up'ed the ante by making claims that all the vm370 security procedures were such that even if I was physically in the machine room, I wouldn't be able to access the documents. So in a moment of weakness, I said that it would take less than five minutes ... I went to the operators console and spent most of the time disabling connectivity to the machine (to anything outside the machine room) ... then I flipped a bit in real storage ... and had access to everything.

So they then wanted to know what kind of countermeasures to that attack would I use (i.e. standard procedure to alternate between attacking and defending). My comment was to remove all the front panel controls to a lockable interface (say keyboard handled by some sort of service processor requiring password) and/or encrypt all the information (i.e. DES hadn't been invented yet ... although the person responsible for DES was student down at Harvard at the time)

for some topic drift ... recent somewhat related thread
https://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007i.html#15 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?

basically the cp67 service at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

including providing access to some number of students and others from various educational institutions in the boston area ... while at the same time, performing some amount of activity involving extremely sensitive corporate information. In the above reference thread ... it was the existance of virtual memory for 370 ... before the announcement that there would be 370 virtual memory.

Another scenario involved the most sensitve corporate data about customers and business operation. The science center had ported apl\360 to CMS for cms\apl. One of the things this allowed was workspace sizes up to the size of the cms virtual machine (while typical apl\360 workspace sizes was 16kbytes or sometimes 32kbytes). In that time-frame, APL was frequently used for business modeling and other things that currently commingly use spreadsheets. Drastically increasing the APL workspace size allowed for business people in corporate hdqtrs to run their applications against large amounts of real data (so remote 2741 terminal access was provided to armonk ... and they sent cambridge tapes containing extremely sensitive customer and business data).

In this time frame, there was one incident of a MIT student doing a looping channel program as a denial of service attack.

for other drift ... there was the use mentioned by these guys ... something that I didn't learn about until much later
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

misc. past posts about security issues raised by allowing access to non-employees and students from various institutions in the Boston area ... while at the same time providing services involving some of the highest sensitive corporate information.
https://www.garlic.com/~lynn/99.html#7 IBM S/360
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/2000g.html#4 virtualizable 360, was TSS ancient history
https://www.garlic.com/~lynn/2001i.html#44 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
https://www.garlic.com/~lynn/2002h.html#60 Java, C++ (was Re: Is HTML dead?)
https://www.garlic.com/~lynn/2002i.html#62 subjective Q. - what's the most secure OS?
https://www.garlic.com/~lynn/2002p.html#37 Newbie: Two quesions about mainframes
https://www.garlic.com/~lynn/2002q.html#47 myths about Multics
https://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003g.html#5 Any DEC 340 Display System Doco ?
https://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
https://www.garlic.com/~lynn/2003g.html#29 Lisp Machines
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
https://www.garlic.com/~lynn/2004e.html#36 NSF interest in Multics security
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#45 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005f.html#63 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005o.html#34 Not enough parallelism in programming
https://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
https://www.garlic.com/~lynn/2005p.html#20 address space
https://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006h.html#14 Security
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
https://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
https://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006o.html#19 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006w.html#3 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2006x.html#19 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 11:08:54 -0600
Al Balmer <albalmer@att.net> writes:
<G> Most non-experts don't know such programs exist. They don't even know they need them.

early in cp67 ... it was modified to automatic reipl/reboot after failure ... this would get things back up within possibly a minute or two for login. recent post/reference
https://www.garlic.com/~lynn/2007d.html#22 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#23 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?

however, as more and more service virtual machines were created ... the operator still had to manually login and get each of them operational. some of this is mentioned in recent thread talking about service virtual machines ... and their currently being referred to as virtual appliances ... some recent references
https://www.garlic.com/~lynn/2007d.html#23 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#66 Is computer history taugh now?
https://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?

however, as part of some automated benchmarking I was working on ... I created the autolog command ... as well as change to automatically execute an "autolog" for a startup service virtual machine (which could be programmed to execute autologs for other services) ... as part of standard ipl/boot. lots of past posts referring to work on automated benchmarking, workload profiling, and stuff leading up to what is current referred to as capacity planning
https://www.garlic.com/~lynn/submain.html#bench

it turns out that the autolog features started to find a lot of use for production operation ... and eventually found its way out in the product in vm370 release 3. old email references
https://www.garlic.com/~lynn/2006w.html#email750102
in this post
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
and
https://www.garlic.com/~lynn/2006w.html#email750430
in this post
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?

even more topic drift ...
https://www.garlic.com/~lynn/2007i.html#20 John W. Backus, 82, Fortran developer, dies

I've periodically claimed that one of the reasons that so much of the stuff that I was doing at the science center was picked up for product shipment ... was that a lot of the corporation had been extremely preoccupied with Future System project ... and after it was killed, there was a lot of scurrying around to try and get stuff (back) into the 370-based product pipeline.

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 12:15:10 -0600
Morten Reistad <first@last.name> writes:
And the set of cheap servers will prove to be a lot better solution when implemented right, because it gives you diversity in network topology, energy supply and geography, something a cluster can never give you.

when we were doing ha/cmp product ... we didn't make much difference between lots of cheap servers and clusters ... from development and architectual design standpoint. it seems to mainly come from vendors pricing policies as opposed to any fundamental architectual difference
https://www.garlic.com/~lynn/subtopic.html#hacmp

we were looking somewhat at the higher-priced end of the market for ha/medusa stuff
https://www.garlic.com/~lynn/lhwemail.html#medusa
and
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15

and some of the bandwidth requirements for geographic survivabilty stuff
https://www.garlic.com/~lynn/submain.html#available

recent posts mentioning geographic survivability
https://www.garlic.com/~lynn/2007.html#29 Just another example of mainframe costs
https://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs
https://www.garlic.com/~lynn/2007e.html#16 Attractive Alternatives to Mainframes
https://www.garlic.com/~lynn/2007e.html#38 FBA rant
https://www.garlic.com/~lynn/2007f.html#56 Is computer history taught now?
https://www.garlic.com/~lynn/2007h.html#76 John W. Backus, 82, Fortran developer, dies

but we also did simple, much less expensive stuff using off-the-shelf components and leverage networking protocol stack and internet topology ... like for original payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway
and recent post
https://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 12:25:59 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
The IRS gets it's cut (and so do the states) no matter who makes the money. Living on unreported income is how Al Capone got brought down; and the bookkeeping practices today make it *really* hard to hide extra income. "Money Laundering" doesn't even work; it merely allows you to pay taxes in illegal income so the IRS doesn't go after you.

part of this is that the criminal justice system can get all bolixed up with proving guilt beyond resonable doubt ... even when all parties know the true circumstances. the tax system has effectively been able to invert the problem ... rather than the gov. having to prove there was an illegal source ... all the gov. has to do is claim unreported and then it shifts back to the accused to dig themselves out of the situation (in effect prove that they are innocent ... as opposed to the gov. proving guilt ... i.e. since you have a home ... how did you pay for it?).

this is analogous ... but completely different to past discussions about possibly being able to change the burden of proof in retail payment transactions; recent reference
https://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?

for totally other topic drift ... some work in X9.59 standards work regarding being able to assist in resolving disputes regarding invoice or bill-of-materials involved in transaction
https://www.garlic.com/~lynn/aadsm26.htm#61 crypto component services - is there a market?

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 14:31:27 -0600
greymaus writes:
That all will take a while to digest. Generally, good stuff, with the important point that more education is needed generally in a modern economy.. Latin America would still not have the sort of education system that Ireland had, even in the 1940's-50's. There are a lot of factors to consider.

re:
https://www.garlic.com/~lynn/2007i.html#18 John W. Backus, 82, Fortran developer, dies

there were some number of similar studies of domestic population groups ... i.e. total costs against total economic contributions ... being either positive (contributing less economically than costing) or negative.
http://www.cis.org/articles/2004/fiscalexec.html
http://www.gao.gov/cgi-bin/getrpt?HEHS-95-133

one of the studies from the 1990 census put half of the high school graduation age group as functionally illiterate and falling into the category of likely costing the society more than they contribute (needing various forms of gov. and social assistance and subsidies).

something similar shows up in some of the social security ("pay as you go") studies ... comparing ratios of 30+ contributing to every person receiving ... then what happens as it drops to 6:1 contributing per person receiving ... and then projections what happens when the ratio drops to less then 1:1 ... is there a tipping point when the amount available for assistance/subsidies becames smaller than the required outlays.

a few/sample past posts mentioning 1990 census study that found half of high school aged graduates were functionally illiterate.
https://www.garlic.com/~lynn/2002k.html#45 How will current AI/robot stories play when AIs are real?
https://www.garlic.com/~lynn/2003i.html#28 Offshore IT
https://www.garlic.com/~lynn/2003i.html#45 Offshore IT
https://www.garlic.com/~lynn/2003i.html#55 Offshore IT
https://www.garlic.com/~lynn/2003p.html#33 [IBM-MAIN] NY Times editorial on white collar jobs going
https://www.garlic.com/~lynn/2004b.html#42 The SOB that helped IT jobs move to India is dead!
https://www.garlic.com/~lynn/2004d.html#18 The SOB that helped IT jobs move to India is dead!
https://www.garlic.com/~lynn/2004h.html#18 Low Bar for High School Students Threatens Tech Sector
https://www.garlic.com/~lynn/2005e.html#48 Mozilla v Firefox
https://www.garlic.com/~lynn/2005g.html#43 Academic priorities
https://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
https://www.garlic.com/~lynn/2006l.html#63 DEC's Hudson fab
https://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness

Latest Principles of Operation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Latest Principles of Operation
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 25 Apr 2007 14:43:10 -0600
Howard Brazee <howard@brazee.net> writes:
That makes sense. But continuing that thought, I see Apple, which doesn't try to make its OS be all things for all people (and hardware manufacturers). Even if it *is* UNIX.

nominally the argument is that complexity contributes to confusion and failures ... KISS is frequently better because it minimizes confusion which can be major source of failures, vulnerabilities, threats and exploits. however, another argument is that the solution paradigm has to match the environment ... that there can be enormous amount of complexity introduced when the solution paradigm is a mismatch for the environment that it is being applied to.

slightly related thread discussing f18/f14, f16/f15, as well as f20 (with even a little computer related stuff sprinkled in) ... warning quite a bit of thread drift ... even tho there was a lot of numerical intensive computing that went into f16, f18, f20, etc:
https://www.garlic.com/~lynn/2007i.html#3 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#4 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#6 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#10 John W. Backus, 82, Fortran developer, dies

Latest Principles of Operation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Latest Principles of Operation
Newsgroups: bit.listserv.ibm-main,alt.folkore.computers
Date: Wed, 25 Apr 2007 15:21:31 -0600
Howard Brazee <howard@brazee.net> writes:
That makes sense. But continuing that thought, I see Apple, which doesn't try to make its OS be all things for all people (and hardware manufacturers). Even if it *is* UNIX.

re:
https://www.garlic.com/~lynn/2007i.html#25 Latest Principles of Operation

apple os (and next before it) starts out with a MACH "microkernel" basis ... could be considered striving for KISS ... somewhat like the original CP67, as an extremely well focused microkernel. The morph from CP67 to VM370 included work by people with much more of traditional operating system training. Over the years, many found that the extreme simplicity of the kernel made it easy to change/add/modify on an adhoc basis. Unfortunately many such years of such adhoc approach to dealing with something that was suppose to be a microkernel (rather than operating system) ... eventually results in a lot of bloat and spaghetti code

past reference to comment about simple can be frequently much harder than complex ... and it should be done with there is nothing left to remove ... as opposed to it being done when there is nothing left to add.
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#30 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies

more recently there have been comments about simple virtual machine microkernels may be solution to various significant security issues in the personal computing market place ... dynamically opening up a traditional operating system in a "padded cell" virtual machine when it needs to do various kinds of internet/network operations ... and then collapsing and discarding most of the environment when finished.

lots of past posts referring to various microkernel activities:
https://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
https://www.garlic.com/~lynn/95.html#0 pathlengths
https://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001h.html#11 checking some myths.
https://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
https://www.garlic.com/~lynn/2001k.html#45 SMP idea for the future
https://www.garlic.com/~lynn/2001l.html#25 mainframe question
https://www.garlic.com/~lynn/2001m.html#47 TSS/360
https://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
https://www.garlic.com/~lynn/2003.html#60 MIDAS
https://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)
https://www.garlic.com/~lynn/2003j.html#72 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#5 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003k.html#24 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#28 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#30 IBM channels, was Re: Microkernels are not "all or nothing"
https://www.garlic.com/~lynn/2003k.html#37 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
https://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#56 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005c.html#63 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#83 IBM to the PCM market

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 18:06:02 -0600
Morten Reistad <first@last.name> writes:
So, the file system will have to handle being yanked at any time. We have the invention of log structured file systems for this. Such file systems were introduced as the default in Linux in 2003.

Which means the file system will backtrack on the next mount, and go to the last valid checkpoint. Then, the file system is in a known state, and applications functional. (i.e. no zapped indices etc). Your data may be lost, but that is what you have for yanking the media.


small digression ... the normal use of log structured file system was as much about attempting to do arm optimization for writes ... as it was for integrity purposes ... as opposed to journaled/logging file systems (where changes are journaled/logged in manner similar to database transactions).

as improvements in disk performance lagged further and further behind improvements in other system components ... there was more and more work done on attempting to compensate for the relative disk degradation. extensive use of (electronic memory) caching worked for reads (involving data that was likely to be reused).

logs had the characteristic that they involved sequential contiguous writes ... possibly in large block transfers ... minimizing arm motion and rotational delays that have been the primary disk thruput bottleneck.

some number of database systems have done things like fast commit ... where the transaction was considered "committed" as soon as the journaled changes had been written to log (in highly optimized sequential contiguous writes) ... and the actual database records remained cached in storage ... where "lazy" writes to the "home" database position attempted to collect numerous changed/updated records located in physical proximity for writing.

log structured filesystems would extend to doing all writes to sequential contiguous locations. the issue was a periodic "garbage collection" process that attempted to re-organize records to file sequential ordering instead of sequential location ordering based on temporal sequence of the write requests. the problem was that the "garbage collection" overhead could more than offset improvements by doing all writes to sequential contiguous locations.

minor historical note ... one of the primary individuals that did work on bsd fast file system implementation and then log structured filesystem implementation was later hired by ha/cmp project to consult on doing a geographically distributed filesystem ... misc. past posts mentioning ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
and geographically distributed operation
https://www.garlic.com/~lynn/submain.html#available

the first such (unix) journaled/logging filesystem was JFS done for AIX ... which only handles filesystem control/metadata changes ... not actual file data changes/writes. work on early 801/risc had included stuff for "database" memory ... i.e. memory map all you data to area that had fine-grain storage alteration tracking. Instead of having application code to explicit call log manager with pointers to all changes ... which then got batched for writing to the log when commit was called ... there could just be careful memory mapping of the data ... and when commit was called ... the commit/log processor would scan memory for all changes ... which then get logged.

So the exercise for AIX3.0 for RS/6000 (rios) was to remap all unix filesystem control/metadata to special "database" memory mapped region. The original unix code didn't have to be modified to track all metadata changes ... just the insertion of "commit" calls at carefully selected points. The commit/log routine then would scan the "database" memory mapped region for all storage alterations ... and write them to the log/journal.

An issue came up for the Palo Alto unix organization about porting the code to non-801 architecture machine (w/o the hardware database memory support). They had to go back thru all the unix filesystem code ... inserting changed/logged calls at all the appropriate places. One of the (unfortunate?) side results ... was that they were able to show that the explicit changed/logged calls were actually more efficient and better performance than the scanning needed for the database memory implementation.

past posts mentioning log structured filesystems
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/2000c.html#24 Hard disks, one year ago today
https://www.garlic.com/~lynn/2001f.html#59 JFSes: are they really needed?
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2004g.html#22 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005l.html#41 25% Pageds utilization on 3390-09?
https://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
https://www.garlic.com/~lynn/2006j.html#3 virtual memory
https://www.garlic.com/~lynn/2006j.html#10 The Chant of the Trolloc Hordes
https://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy)

various past posts/threads mentioning database memory
https://www.garlic.com/~lynn/2002b.html#33 Does it support "Journaling"?
https://www.garlic.com/~lynn/2002b.html#34 Does it support "Journaling"?
https://www.garlic.com/~lynn/2003c.html#49 Filesystems
https://www.garlic.com/~lynn/2003d.html#54 Filesystems
https://www.garlic.com/~lynn/2005n.html#20 Why? (Was: US Military Dead during Iraq War
https://www.garlic.com/~lynn/2005n.html#32 Why? (Was: US Military Dead during Iraq War
https://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance
https://www.garlic.com/~lynn/2006y.html#36 Multiple mappings

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 25 Apr 2007 18:11:45 -0600
re:
https://www.garlic.com/~lynn/2007i.html#23 John W. Backus, 82, Fortran developer, dies

for even more topic drift ... recent article showed up today ...

Fraud was the Cinderella of crimes but that's about to change
http://www.easier.com/view/News/Business/article-111323.html

a couple quotes from above
"Trying to turn financial people into crime officers is doomed to failure."
...
"David Luijerink, head of fraud risk management services at KPMG Forensic believes companies often look in the wrong place for fraudsters."


... snip ...

for instance, past studies have shown (even in the internet age) that the majority of fraud have involved "insiders". misc. past posts mentioning "issues" with insiders:
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2002.html#12 A terminology question
https://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#37 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2005g.html#33 Good passwords and security priorities
https://www.garlic.com/~lynn/2005g.html#37 MVS secure configuration standard
https://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
https://www.garlic.com/~lynn/2005i.html#11 Revoking the Root
https://www.garlic.com/~lynn/2005j.html#52 Banks
https://www.garlic.com/~lynn/2005k.html#1 More on garbage
https://www.garlic.com/~lynn/2005k.html#55 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005o.html#2 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006h.html#26 Security
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#33 Password Complexity
https://www.garlic.com/~lynn/2006p.html#9 New airline security measures in Europe
https://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#42 On sci.crypt: New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2006x.html#14 IBM ATM machines
https://www.garlic.com/~lynn/2007.html#42 The logic of privacy
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#11 Decoding the encryption puzzle
https://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007

Does anyone know of a documented case of VM being penetrated by hackers?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Does anyone know of a documented case of VM being penetrated by hackers?
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Thu, 26 Apr 2007 08:11:39 -0600
re:
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?

for a little topic drift ... a little about virtual machine assurance in recent post to ibm-main
https://www.garlic.com/~lynn/2007i.html#26 Latest Principles of Operation

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: 26 Apr 2007 08:49:18 -0700
On Apr 26, 1:04 am, Brian Inglis <Brian.Ing...@SystematicSW.Invalid> wrote:
It was either that or add non-IBM code from the SHARE Waterloo tapes into the product and credit the authors. If you or others inside didn't write it, they then redesigned and reimplemented the idea from SHARE. FOr example RETRIEVE for command line recall allowing editing replaced the equivalent SHARE code attached to PA2 IIRC.

re:
https://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran developer, dies

internal datacenters and external customers were comparable. there was study in the early 80s ... that the "internal" change/update collections were comperable to the waterloo share tape change/update collections (about the same aggregate size in magnitude and offered similar features); but done by internal datacenters (for much the same reason that external customers were doing change/updates).

there was some copying ... but mostly things were going on independently and frequently coming up with similar solutions. there was possibly slightly more pervasive distribution of such stuff internally ... since there wasn't the issue of crossing corporate boundaries ... as well as the increasingly pervasive use of the internal networks .... folklore about internal network significantly aided the evolution of REX(X) language in the 70s ... previous posts:
https://www.garlic.com/~lynn/2006p.html#28 Greatest Software Ever
Written?
https://www.garlic.com/~lynn/2006p.html#31 "25th Anniversary of the
Personal Computer"
https://www.garlic.com/~lynn/2006r.html#7 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?

to reference here (gone 404 but lives on at wayback machine)
https://web.archive.org/web/20020506063424/http://computinghistorymuseum.org/ieee/af_forum/read.cfm?forum=10&id=21&thread=7

One of the scenarios going the other way ... i had done DUMPRX in the early 80s
https://www.garlic.com/~lynn/submain.html#dumprx

initially somewhat as demonstration of the new scripting language (rexx) and its capability ... i.e. show that in three months working half-time ... write a replacement for the existing dump (problem analysis tooL) in rexx with ten times the function and ten times the performance (of the original assembler). Since this was also around the time that there was talk about forcing OCO ... that having major application in an interpreted language ... that it would still force them to ship source (if they chose to ship dumprx). Eventually, it was used in nearly every internal datacenters and by all PSRs (i.e. internal people tasked with resolving system problems at customer datacenters) ... but for whatever reason they never agreed to ship it.

However, i got approval to give a dumprx talk at share meeting ... and i spent the whole talk about how i did the implementation. Within a couple months ... similar implementations started to show up at customer shops.

past posts mentioning transition to OCO (object code only)
https://www.garlic.com/~lynn/2001e.html#6 Blame it all on Microsoft
https://www.garlic.com/~lynn/2002c.html#4 Did Intel Bite Off More Than It Can Chew?
https://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
https://www.garlic.com/~lynn/2002p.html#3 IBM OS source code
https://www.garlic.com/~lynn/2002p.html#7 myths about Multics
https://www.garlic.com/~lynn/2003k.html#46 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2004m.html#47 IBM Open Sources Object Rexx
https://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
https://www.garlic.com/~lynn/2005c.html#42 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#34 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005e.html#35 Thou shalt have no other
gods before the ANSI C standard
https://www.garlic.com/~lynn/2005f.html#15 Where should the type
information be: in tags and descriptors
https://www.garlic.com/~lynn/2005j.html#29 IBM Plugs Big Iron to the
College Crowd
https://www.garlic.com/~lynn/2005j.html#41 TSO replacement?
https://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005u.html#57 IPCS Standard Print Service
https://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
https://www.garlic.com/~lynn/2006f.html#38 Over my head in a JES exit
https://www.garlic.com/~lynn/2006j.html#29 How to implement Lpars within Linux
https://www.garlic.com/~lynn/2006j.html#33 How to implement Lpars
within Linux
https://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006o.html#14 SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#54 The Perfect Computer - 36 bits?

Latest Principles of Operation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Latest Principles of Operation
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 26 Apr 2007 12:04:40 -0600
rfochtman@ibm-main.lst (Rick Fochtman) writes:
That increased instruction set allows for vastly increased capability, in spite of the perceived complexity. Simple applications can still be coded using simple instructions, but more complex requirements can be met more simply and efficiently by using some of those "added instructions" that seem to lead to complexity.

Complexity is far too often used as an excuse for incompetence or laziness; not always or even most of the time, but still far too often. You don't let a carpenter into your house if he doesn't know how to use his tools, do you????


re:
https://www.garlic.com/~lynn/2007i.html#25 Latest Principles of Operation
https://www.garlic.com/~lynn/2007i.html#26 Latest Principles of Operation

well, i remember the hassle to get compare&swap instruction into the 370 architecture. Charlie had invented compare&swap instruction when he was working on smp kernel fine-grain locking for cp67 at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

the "redbook" 370 architecture owners claimed that everybody (namely the POK favorite son operating system people) thot that test&set was totally adequate for all multiprocessor support. in order to justify getting compare&swap instruction into 370 architecture, we had to come up with a whole boatload of justifications for compare&swap instruction that weren't specific to multiprocessor operation. thus was born the stuff in principle of operations about using compare&swap instruction for application multithreaded operation (regardless of whether or not it was multiprocessor environment). lots of past posts mentioning multiprocessor support and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp

it is sometimes relative. i've claimed that John came up with risc/801 as part of going to the opposite extreme after the extremely complex future system project failed ... misc. past posts mentioning failed future system project
https://www.garlic.com/~lynn/submain.html#futuresys

and lots of past post mentioning 801, romp, rios, iliad, fort knox, somerset, power/pc, etc
https://www.garlic.com/~lynn/subtopic.html#801
and old email with 801 references
https://www.garlic.com/~lynn/lhwemail.html#801

Supposedly future system project was a countermeasure to clone controllers ... something I got (at least partially) blamed for from a project that I worked on as undergraduate in the 60s producing our own clone controller
https://www.garlic.com/~lynn/submain.html#360pcm

also some "FS" quotes referenced in this post
https://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
from article by former executive here
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm

The FS effort and subsequent failure ... can also be considered as contributing to the uptake of clone processors (in part because of the dearth of items in the 370 product pipeline) a few recent posts
https://www.garlic.com/~lynn/2007g.html#55 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)

and after the failure of the FS project ... there was a rush to get stuff back into the 370 product pipeline. Recent post attributing that as big part of the reason that the product group shipped so much of my code (since I continued to develop 370-based software all thru the FS activity)
https://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran developer, dies

and another recent posting touching on some stuff that went on in the FS era
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#29 Does anyone know of a documented case of VM being penetrated by hackers?

another stop-gap effort to try and quickly fill the 370 product pipeline (after failure of FS project) was 303x. The standard processor development cycle was 7-8yrs ... and they needed to get something out much quicker than that ... since starting the 370-xa/3081 wouldn't be out before the early 80s.

So they took they 370/158 microcode engine ... and stripped out the 370 microcode support ... leaving just the integrated channel microcode and packaged it as the 303x "channel director". Then the 3031 was a 370/158 microcode engine with just the 370 microcode support (and no integrated channel microcode) paired with a "channel director". The 3032 was a 370/168-3 repackaged to work with "channel director". The 3033 started out simply being 168 wiring diagram mapped to newer chip technology. Recent posts about enormous effort to hurry up and get 303x out the door after failed FS project:
https://www.garlic.com/~lynn/2007d.html#21 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#62 Cycles per ASM instruction
https://www.garlic.com/~lynn/2007e.html#32 I/O in Emulated Mainframes
https://www.garlic.com/~lynn/2007e.html#40 FBA rant
https://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
https://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#23 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#29 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals?

the other aftermath of the FS project failure was that POK lab convinced corporate to shutdown the VM development group, decommit the product, and transfer all the people to POK in order to work on MVS/XA ... also attempting to shorten the typical development time. Endicott was eventually able to salvage the product mission and one or two of the people.

ANN: Microsoft goes Open Source

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ANN: Microsoft goes Open Source
Newsgroups: alt.folklore.computers
Date: Thu, 26 Apr 2007 12:25:55 -0600
jmfbahciv writes:
Of course people can learn new things. I'm not talking about that. Would you hire an elephant to dance a ballet? Would you hire a ballet dancer to haul logs out of the forest? It has to do with not putting a person in a position where, no matter how hard he tries, his result will not be adequate. It makes the employee very unhappy and you don't get the work done. If you assign this guy work of the type he excels at, you'll get a lot more done.

careful what you suggest ... you may find all tasks being reduced to the lowest common denominator so tasks & people are fully interchangeable w/o regard to skills or experience.

this is analogous to reference in prior post about managers ... instead of spending 90percent of their time with the 10percent least productive employees (attempting to double their productivity) ... they should spend 90percent of their time with the 10percent most productive employees (attempting to double their productivity ... which frequently could nearly double the overall group's total productivity).
https://www.garlic.com/~lynn/2007e.html#47 time spent/day on a computer

Internal DASD Pathing

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internal DASD Pathing
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 26 Apr 2007 13:42:49 -0600
Bob.Richards@ibm-main.lst (Richards.Bob) writes:
3880-xx Controller series followed by the 3990-xxx series

DASD was 3380-D, 3380-E, 3380-J, 3380-K, 3390-1, 3390-2, 3390-3 (today's major image) and 3390-9 (a true SLED pulled by crippled and maimed dogs)

Yes, the 3380s had four paths. Do not recall if it was ever increased.


3830 disk controller had dual channel along with "string switch" for 3330 ... allowing for four paths total (i.e. string connecting to two different controllers, each of which could connect to two different channels)

3880 disk controller had four channel interfaces ... and 3380 "string switch" (a-box) allowed 3380 string to be connected to two different controllers for eight total paths.

Evolution of the DASD storage control
http://www.research.ibm.com/journal/sj/282/ibmsj2802C.pdf

not to be too harsh about comment in the above about 3880 having better performance ... but some recent posts that touched on getting 3880 out the door ... as well as little discussion of dynamic pathing
https://www.garlic.com/~lynn/2007h.html#1 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#3 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#4 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#5 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#6 21st Century ISA goals?
https://www.garlic.com/~lynn/2007h.html#9 21st Century ISA goals?
IBM Jargon: A-Box n. A primary storage unit: the one closest to the controller. Most 370 storage peripherals come in two flavours. The A-Box (also called head of String, or Model A) either houses the controller (e.g., 3422), is the controller (e.g., 3480), or connects to the controller. The B-Box (Model B) is used for extending the string. Some strings can be connected to the controller at both ends, in which case the unit at the end of the string is usually a Model D.

... snip ...

3380 "history" here with A & B boxes:
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380b.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380c.html
minor mention of a-box, head-of-string function:
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380d.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380e.html

from above:
A string of Standard model 3380s can consist of a single 3380 Model A04 or AA4 and up to three 3380 Model B04 units. A string of Extended Capability 3380s can consist of one 3380 Model AD4 or AE4 and up to three 3380 Model BD4 and BE4 units, in any combination. Two strings of 3380s can be attached to each storage director of a 3880 Model 3 or cache storage control Model 23. An A04 string is not supported by the Model 23. Strings headed by an AA4, AD4 or AE4 must attach to two storage directors (usually on two separate 3880 Storage Controls). An AA4 string and an Extended Capability string can be attached to the same storage directors.

... snip ...

at one point i made a forey into redoing the (3880) controller dynamic pathing architecture implementation ... as part of significantly extending & simplifying ("dynamic pathing simplification") capability for virtualized operation ... but got into all sort of issues regarding compatibility with implementation already in the field.

Internal DASD Pathing

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internal DASD Pathing
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 26 Apr 2007 15:08:21 -0600
Howard Brazee <howard@brazee.net> writes:
A bit off topic: I find your input to these threads in general to be quite useful. They appear to take a fair amount of work - are they part of your jobs, or is this just a style you are comfortable with?

re:
https://www.garlic.com/~lynn/2007i.html#33 Internal DASD Pathing

i had done some amount of the semi-automated computer conferencing via email (copy list) mechanism on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

in the late 70s and early 80s ... and got blamed for something called "tandem memos" (there was even a nov81 datamation article about tandem memos). tandemo memos were somewhat spawned by various trip reports visiting Tandem after Jim left SJR. somewhat recent postings referencing Jim and his departure from SJR:
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing

somewhat as an outcome of various investigations into the "tandem memo" phenomena ... there were decisions to deploy officially sanctioned corporate computer conferencing capability.

there was also a researcher hired that sat in the back of my office for nine months and studied how i communicated; phone, face-to-face, email, instant messeging, etc. they had copies of my incoming and outgoing email and logs of all instant messages. The resulting report was also published as a stanford phd thesis (joint between ai and language) and the subject matter for some number of papers and books. some related posts mentioning computer mediated conferencing
https://www.garlic.com/~lynn/subnetwork.html#cmc

never got paid for it ... frequently closer to the opposite ... minor reference:
https://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer

there were sometimes jokes in the mid-80s about various subject threads having gotten "wheeler'ized" ... i.e. when possibly 80-90% percent of the characters in some corporate/world wide discussion were found to originate from my keyboard. most consider that i have extremely mellowed since then ... and have been doing it for 30 yrs or so

somewhat drifting back to the original topic ... misc. collected posts about getting to play in the disk engineering (bldg. 14) and disk product test (bldg. 15) labs.
https://www.garlic.com/~lynn/subtopic.html#disk

ANN: Microsoft goes Open Source

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ANN: Microsoft goes Open Source
Newsgroups: alt.folklore.computers
Date: Thu, 26 Apr 2007 15:51:46 -0600
krw <krw@att.bizzzz> writes:
Yes, I remember that conversation. I still believe that manager doesn't NEED to manage the most productive and any effort to do so may be counterproductive.

Time spent managing the least productive is at least time not impeding the most, ironically turning the least productive into the most productive. ;-)


re:
https://www.garlic.com/~lynn/2007e.html#47 time spent/day on a computer
https://www.garlic.com/~lynn/2007i.html#32 ANN: Microsoft goes Open Source

it wasn't intended to mean that time spent supporting the ten percent most productive ... was "managing" ... not in the "command and control" sense (ala Boyd's briefing on organic design for command and control). some study showed that effective managers anticipating and removing obsticals for their ten percent most productive ... may be able to improve their productivity by 50-100 percent (or sometimes more).

however, if unable to perform that duty ... then 2nd best is to just stay out of the way.

here is one from May87 ... my hard copies are from 83, i think we may have gotten one of the first briefings of this shortly after it had been created.
http://www.belisarius.com/
https://web.archive.org/web/20010722050327/http://www.belisarius.com/

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

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Thu, 26 Apr 2007 16:18:35 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
however, as more and more service virtual machines were created ... the operator still had to manually login and get each of them operational. some of this is mentioned in recent thread talking about service virtual machines ... and their currently being referred to as virtual appliances ... some recent references
https://www.garlic.com/~lynn/2007d.html#23 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#66 Is computer history taugh now?
https://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?


re:
https://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran developer, dies

for even more drift, news item from today about the proliferation of (some) virtual appliances:

Parallels Technology Network announced
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9017923

from above:
Parallels, makers of the popular Parallels Desktop for Mac software that enables Intel-based Macs to run Windows side-by-side without having to reboot, on Thursday announced the Parallels Technology Network (PTN). The goal of the new resource is to consolidate the efforts of developers working on third-party Parallels 'Virtual Appliances.'

... snip ...

Internal DASD Pathing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internal DASD Pathing
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 26 Apr 2007 16:41:31 -0600
re:
https://www.garlic.com/~lynn/2007i.html#33 Internal DASD Pathing
https://www.garlic.com/~lynn/2007i.html#34 Internal DASD Pathing

minor addenda ... to previous topic drift ... this index of old email
https://www.garlic.com/~lynn/lhwemail.html

also contains a URL for an eserver (since renamed IBM Systems) magazine article that appeared two yrs ago ... although they got some of the details slightly garbled. I actually haven't seen the copy of the physical magazine ... they had sent a photographer to the house for photo shoot ... and something from that supposedly shows up in the magazine.

John W. Backus, 82, Fortran developer, dies (Actually, Working under the table!)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies (Actually, Working under the table!)
Newsgroups: alt.folklore.computers
Date: Thu, 26 Apr 2007 17:58:33 -0600
"Micheal H. McCabe" <mhmccabe@alltel.net> writes:
Getting this back on track regarding computers, does anybody know how badly the data-processing arm of the IRS was injured by the floods last June? Early reports seemed to indicate severe damage to records and equipment kept in the basement of the Headquarters Building.

how many dataprocessing modernization projects have there been at the IRS in the past 20yrs? i heard rumors that the newer generation of object coders have been finding it difficult to scope out what is going on in the 60s 360 mainframe assembler coding.

a dec91 article

TRW Awarded IRS Contract for Tax Systems Modernization
http://20www.unclefed.com/Tax-News/1991/Nr91-125.html

An aug94 report
http://www.eff.org/Infrastructure/Govt_docs/npr_it_082294.report

jun98 history
http://clinton3.nara.gov/pcscb/rmo_irs.html

may03 GAO report
http://www.gao.gov/htext/d03796t.html

a nov04 article

IRS modernization left with lean budget
http://www.gcn.com/online/vol1_no1/27990-1.html

feb2005 GAO high-risk update report:
http://www.gao.gov/htext/d05350t.html

includes

• IRS Business Systems Modernization[C].

feb2007 testimony
http://budget.senate.gov/democratic/testimony/2007/Everson_testimony021407.pdf

includes request of $282m for Business Systems Modernization in FY2008 budget.

Does anyone know of a documented case of VM being penetrated by hackers?

Refed: **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Does anyone know of a documented case of VM being penetrated by hackers?
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Thu, 26 Apr 2007 18:32:57 -0600
George Haddad wrote:
The last major hole I can recall was in the late 80s or early 90s IIRC, where it was discovered that when sending an SMSG to an SVM (I think it was RSCS) which included a CP command, the SVM would blindly execute multiple CP commands if they were chained with CP Newline character. If the SVM had any special privs ...well you get the idea. It was patched very quickly.

re:
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#29 Does anyone know of a documented case of VM being penetrated by hackers?

should have been mid-70s ... not late 80s ... at least on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

from long ago and far away ...

Date: 80/12/16 10:52:11
To: wheeler

I never came back last night, but I did speak to XXXXXX about that file. He points out that RSCS probably translates a pound sign to a question mark for display (to eliminate problems with embedded commands in messages, which caused some difficulty a few years ago). So the file is probably ok; perhaps you can check with XXXXX and find out.

By the way, what I did last night was to tune my oil burner. I don't know how you people out there heat (on the 3 days a year when the temperature gets below 68), but if you have an oil burner (even just for hot water), you ought to look into doing a tune-up on it. The lab here has a kit we can borrow for the purpose, and in less than an hour I got the efficiency from 60% to about 74%.


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

and now for some networking thing completely different from the late 80s

Date: 7 May 1987, 19:35:58 EDT
To: wheeler
From: somebody in corporate hdqtrs
Subject: Large Files...

Lynn:

We are getting requests to handle 500MB files.. EC releases, Chip Designs, software, and documentation... (one group has a 3BB file requirement!!).. Altho' the 500MB req't is coming within the next few months...

Have you done any thinking during your HSDT work.. on what the limits might be on large files.. compared to our networking software and communication link capacity...??? I'm thinking that there must be a limit... or a knee on the curve which says.. use a courier service.. rather than the network... Have you been able to develop any attributes, characteristics, etc.. on 'large files'...that could be helpful to planning and operating with these large files...??


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

i.e. HSDT (high-speed data transport) was working with handling large files ... recent post referencing helping contribute to bringing in the RIOS chipset a year early
https://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
https://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings

misc. posts mentioning HSDT activities ... dating back to 1980 time-frame
https://www.garlic.com/~lynn/subnetwork.html#hsdt

as well as some activity working with various people at univ. and NSF ... old email:
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

and misc. postings mentioning BITNET and/or EARN
https://www.garlic.com/~lynn/subnetwork.html#bitnet

Best practices for software delivery

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Best practices for software delivery
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 27 Apr 2007 09:30:34 -0600
barry.a.schwarz@ibm-main.lst (Schwarz, Barry A) writes:
Internet is only a reasonable approach when companies are willing to provide the same level of quality control over their web sites that they do for their traditional media. Other than the CBT site (thank you Sam) none of the others I deal with do. When I'm trying to download the solution to a problem, I don't need a link to a page that doesn't exist, some distracting animation, annoying pop-ups, notification that the web site prefers a different browser, brain dead interfaces that insist you enter the same information repeatedly, options that are ignored, and out of date content.

old email here from somebody in corporate hdqtrs (in this x-over thread from vmesa-l list) ... asking if HSDT project had been thinking about how to do this sort of stuff ...
https://www.garlic.com/~lynn/2007i.html#39 Does anyone know of a documented case of VM being benetrated by hackers?

this was in the timeframe when we had been doing work w/NSF on what was to become NSFNET (tcp/ip is the technology basis for the modern internet, but we claim that NSFNET was the operational basis for the modern internet, aka high-speed backbone providing internetworking of networks). some of the old email on the subject from the period
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

lots of past posts mentioning HSDT project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Fri, 27 Apr 2007 10:25:52 -0600
krw <krw@att.bizzzz> writes:
Long ago most banks decided that they didn't want to service the masses. Many only want the largest accounts, so structure their accordingly. Most are better off "banking" with a credit union. With the current lax rules for CU members, it only makes sense for most individuals to ignore all federal banks completely.

re:
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies

i believe that there is some number that possibly as much as 1/3rd of the population is "unbanked" ... in large part based on financial infrastructure cost structures (not so much financial infrastructure want the largest accounts ... but their cost structure doesn't easily support the lower end of the market).

earlier reference to financial infrastructure costs
https://www.garlic.com/~lynn/2007e.html#65 Securing financial transactions a high priority for 2007

misc. unbanked references (quick use of search engine)

Bringing Unbanked Households Into the Banking System
http://www.brook.edu/metro/capitalxchange/article10.htm
"Tapping the Unbanked Market" Symposium
http://www.fdic.gov/consumers/community/unbanked/index.html
Stored Value Cards: An Alternative for the Unbanked?
http://www.ny.frb.org/regional/stored_value_cards.html
Topics: Unbanked (Those without a bank account)
http://www.bos.frb.org/consumer/topics/unbanked.htm
Consumer Spending Trends of Banked, Unbanked Prepaid Cardholders
http://www.paymentsnews.com/2006/07/consumer_spendi.html
Reaching Out to The Unbanked; A high-tech alternative to traditional banking
http://usgovinfo.about.com/library/weekly/aa031001a.htm

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Fri, 27 Apr 2007 11:05:21 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
i believe that there is some number that possibly as much as 1/3rd of the population is "unbanked" ... in large part based on financial infrastructure cost structures (not so much financial infrastructure wants the largest accounts ... that their cost structure doesn't easily support the lower end of the market).

re:
https://www.garlic.com/~lynn/2007i.html#41 John W. Backus, 82, Fortran developer, dies

it has (also) been suggested that one of the reasons for the stiff resistant to all the rounds of walmart getting into financial services (over the last decade or so) ... including the latest round with walmart buying an Utah ILC ... is that walmart might change the cost/fee structure in the financial industry

there supposedly was testimony on the flr of the senate in the 90s ... that the purpose of the bank modernization act was so that if you were already bank, you got to stay a bank, and if you weren't already a bank, you wouldn't be able to become a bank (specifically m'soft and walmart) ... old post making reference:
https://www.garlic.com/~lynn/2006k.html#49 Value of an old IBM PS/2 CL57 SX Laptop

quicky use of search engine

Scott's Wal-Mart Defends Banking Plan
http://www.forbes.com/facesinthenews/2006/04/10/walmart-banking-utah-cx_po_0410autofacescan03.html
Congress May End Wal-Mart's Banking Dreams
http://www.consumeraffairs.com/news04/2006/07/congress_walmart_bank.html
Finding Niche Helps New Utah ILC Gain Foothold
http://www.banknet360.com/news/NewsAbstract.do?na_id=6726
Withdrawal of 'Wal-Mart Bank' Bid Called 'Wise Choice'
http://www.cnsnews.com/ViewNation.asp?Page=/Nation/archive/200703/NAT20070319a.html

above references include claim that the Utah ILC was targeted at reducing debit/credit costs (i.e. their Utah ILC could be their own financial acquiring institution, as opposed to being used for consumer branch banking, the debit/credit fees wouldn't change ... but would be paid to themselves). this would be consistent with their class-action anti-trust litigation ... prior reference
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies

Latest Principles of Operation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Latest Principles of Operation
Newsgroups: bit.listserv.ibm-main,alt.folklore.compters
Date: Fri, 27 Apr 2007 13:52:36 -0600
Howard Brazee <howard@brazee.net> writes:
A lot of our smarts is in seeing patterns, simplifying what we are looking for. Occasionally this kind of shortcut causes us to miss things, but pattern recognition allows the chess master to ignore dead ends that poorer players waste time on.

I see craftsmen and artists using tools that are difficult to master - but supply and demand doesn't take that into consideration in setting prices for their goods.


long post warning ...

as an undergraduate ... i did fair share scheduler for cp67 ... or actually dynamic adaptive resource management ... with default policy being fair share; minor recent reference:
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler

but also did a lot of highly optimized pathlength and fastpath stuff. I made jokes about being able to do stuff in zero instructions ... carefully tweaking instructions all over the kernel so that various things happened implicitly ... so scheduler didn't actually have to execute instructions to obtain the desired results (secondary effects of the order of how other things are occurring, of course it helps if you effectively have memorized the source for the complete kernel ... all assembler).

over some yrs, there was complaints that nobody could understand how it worked ... which probably contributed to a lot of it being dropped (simplified) in the morph from cp67 to vm370.

so possibly still part of the recovery in the aftermath of future system project ... recent reference in this post
https://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation

I was given the opportunity to reintroduce the resource manager for vm370 ... among other things, another recent post
https://www.garlic.com/~lynn/2007i.html#21 John W. Backus, 82, Fortran developer, dies

... more topic drift ...

however, they decided that the resource manager should be guinea pig to starting to charge for kernel code ... so i had to spend some amount of time with the business and legal people working on policy for charging for kernel software; i.e. 23jun69 unbundling announcement started charging for application software ... but they used the excuse that kernel software was integral to hardware operation and should still be "free" ... misc. past posts
https://www.garlic.com/~lynn/submain.html#unbundle

... slightly return to topic ...

now, i did fix up some of the more obtuse pieces of (assembler) code ... but there still was quite a bit of complexity in the resource manager ... and people over the yrs would complain that they didn't understand how it worked ... and periodically somebody would make changes in other parts of the kernel resulting in unexplicable affects on scheduling (there was still quite a bit of convoluted code that I justified on being able to do things in fewer instructions and shorter pathlength).

so there was one fly in the ointment, somebody from corporate complained that there weren't any tuning parameters ... which was the state of the art in other products; ... namely the favorite son operating system of the period had a massive table of tuning parameters ... and there were this presentations at SHARE (could put everybody to sleep) about random walks across the tuning parameter table landscape, varying the parameters for all different kinds of workloads and configurations ... attempting to find settings that made some difference.

So I was forced to put in some tuning parameters (before product ship), document them and the backup formulas ... as well as detailed code explanation.

so we roll forward nearly 20yrs ... we are on a marketing swing thru the far east for our ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
also additional thread drift
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
and
https://www.garlic.com/~lynn/lhwemail.html#medusa

... and we are on a call at a large financial institution. One of the people at the meeting (relatively recent graduate) pipes up and asks if i'm the same person associated with the scheduler ... since they had studied me/it at the Univ. of Waterloo.

So I respond politely and asked if the "joke" was discussed.

Now part of the issue with static tuning parameters is that workloads tend to vary from minute-to-minute, day-to-day, week-to-week ... and there was a whole lot of effort that went into the dynamic adaptive implementation to eliminate the requirement for any static tuning parameters. Being forced to add static tuning parameters seemed to be a great step backward in the state-of-the-art. So as to the "joke" ... if dynamic adaptive can adjust for changes in configurations and workloads ... as well as a lot of other things ... why couldn't the dynamic adaptive implementation also adjust to compensate for changes in any static tuning parameters????

misc. past posts mentioning the resource manager "joke":
https://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001l.html#9 mainframe question
https://www.garlic.com/~lynn/2002c.html#16 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002c.html#54 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002i.html#53 wrt code first, document later
https://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue
https://www.garlic.com/~lynn/2005p.html#31 z/VM performance
https://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
https://www.garlic.com/~lynn/2006h.html#22 The Pankian Metaphor
https://www.garlic.com/~lynn/2006y.html#17 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?

latest Principles of Operation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: latest Principles of Operation
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 27 Apr 2007 16:14:09 -0600
ibm-main@ibm-main.lst (Shane) writes:
Which of course made the whole thing too complex. Maybe we need to make it simpler ...

other posts in this thread:
https://www.garlic.com/~lynn/2007i.html#25 Latest Principles of Operation
https://www.garlic.com/~lynn/2007i.html#26 Latest Principles of Operation
https://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation

part of the complexity issue is possible number of things and/or interactions that have to be managed. it is one of the reasons for modular code. it also one of the reasons for hierarchical management infrastructure and recommendations about "span of control" ... ideal number of direct reports is supposedly seven. fully-meshed interaction complexity is something like N-factorial (i.e. 7! is already 5040).

when were consulting with small client/server company on the original payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway

one of the things that we were doing was making the whole gateway operation redundant, including multiple links into strategic places in the internet backbone ... and planning on advertising (alternate) routes in cases of faults. It was in this time-frame that internet backbone transitioned to hierarchical routing ... in attempting to deal with some of the massive scaling complexity issues. As a result, we had to convert to multiple A-record strategy (for alternate paths) as opposed to strategy advertising routes. recent post
https://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip

in the previous post
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation

I had enormously increased the complexity by creating an environment were the particular order of any set of (assembler) instructions, any place the kernel might have secondary effects on other things in the kernel, not only have to take into account individual instruction operation and the purely sequential flow ... but there might be (non-obvious) secondary effects based possibly on the order that things were performed.

In the early 80s, I had done a dump analysis tool
https://www.garlic.com/~lynn/submain.html#dumprx
recent reference
https://www.garlic.com/~lynn/2007i.html#30 John W. Backus, 82, Fortran developer, dies

which was never released as a product, but eventually was in use at nearly all the internal datacenters as well as being used by nearly all the PSRs that were involved in diagnosing (vm) failures kinds at customer shops.

One of the things that I studied was large number of system failures looking for familiar and/or common signatures ... and writing automatic diagnostic processes that looked for numerous, identifiable failure characteristics.

One such problem, somewhat unique to assembler is the additional burden/complexity that is placed on the programmer for managing register contents. A failure mode that I found to occur quite frequently in kernel assembler code was register contents were not as expected ... possibly because of logic flow taking a particular anomolous path. Higher level languages tend to automate that area of complexity (register) management for the programmer ... and failures due to incorrect register contents occur significantly less frequently.

This analysis was one of my motivations behind helping instigate a operating system rewrite project ... with an objective that included significantly reducing complexity (and possibility for failures). some recent references to the operating system rewrite project (which eventually acquired way to much attention, eventually imploding ... somewhat analogous to a "mini" FS failure). misc. recent references to the old rewrite effort:
https://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#24 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#57 ANN: Microsoft goes Open Source

IBM System/360 Model 85: The Bashful Computer

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM System/360 Model 85: The Bashful Computer
Newsgroups: alt.folklore.computers
Date: Fri, 27 Apr 2007 18:31:17 -0600
Quadibloc <jsavard@ecn.ab.ca> writes:
That may be. The blue MIT book noted above claims the 91 and 195 also had reliability problems, and their problems, along with those of the 85, were primarily due to cooling issues.

I do remember running across a web site that talked about severe reliability problems with one Control Data mainframe; so IBM wasn't alone in having problems in the high end.


one of the things i was told about transition from 360/195 to 370/195 ... in addition to some of the newer 370 instructions ... there were also a number of reliability enhancements ... including new fangled 370 (hardware) instruction retry. there was from the guys that were looking at putting (hardware) multithreading into 370/195 (and needing operating system smp support).

misc. past refs:
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005h.html#22 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2006r.html#2 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?

misc. past refs:
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005h.html#22 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2006r.html#2 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007f.html#10 Beyond multicore

Linux: The Completely Fair Scheduler

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux: The Completely Fair Scheduler
Newsgroups: alt.folklore.computers
Date: Fri, 27 Apr 2007 19:59:11 -0600
<mike@emgee.demon.co.uk> writes:
I sure wish you guys could have figured out a way to pass on the knowledge.

For the record I'm older then the reinventors and younger than the original. So you could have told me. Or perhaps I didn't listen :(


previous posts in this thread:
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler

here is long winded post with reference to class at univ. of Waterloo
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation

lots of past posts mentioning resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare

https://www.garlic.com/~lynn/2007f.html#10 Beyond multicore

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 08:58:11 -0600
jmfbahciv writes:
Walmart is trying to do what GM did? Didn't GM just sell that off? I don't remember what they called it.

re:
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies

GM, ATT, and some others ... issued corporate "branded" cards to consumers. GM also offered "awards" ... based on how much you used the card, you got points that took down the price of buying any new GM car. For some topic drift, Ford also had a card issuing unit called the "Associates" that issued cards (that weren't Ford branded). A few yrs ago, the "Associates" was sold off to citigroup ... associates timeline (Ford buys Associates in 1989 and sell it to citigroup in 2000)
http://www.citigroup.com/citigroup/corporate/history/data/associates.htm

Cards are considered to have five participants, 1) consumer, 2) "issuing" financial institution (i.e. bank that issues the card to the consumer, and is financially responsible for the consumer), 3) the card association, 4) the "acquiring" finanical institution (i.e. bank that sponsors the merchant to accept cards and is financially responsible for the merchant), and 5) the merchant.

GM, ATT, etc, were considered "2", issuing financial institution.

in the reference post here:
https://www.garlic.com/~lynn/2006k.html#49 Value of an old IBM PS/2 CL57 SX Laptop

there is reference to walmart's successful class-action anti-trust suit against the card association primarily around the card rules and "interchange fees" ... i.e. the amount that is taken out of what the issuing bank sends to the merchant for all the card charges. "interchange fees" is a combination of a flat per transaction fee plus a percentage of the amount charged. Part of the interchange fees go to the "acquiring" financial institution, part goes to the "card association", and part gets to be kept by the "issuing" financial institution.

In this reference here
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies

walmart said that it would be setting up the Utah ILC for purposes of only being an "acquiring" financial institution for them, sponsoring walmart ability to do/accept card transactions. In addition to the successful anti-trust suit, this would be another way of reducing the effective total costs to walmart (as a merchnat) for accepting card transactions.

other past posts mentioning interchange fees:
https://www.garlic.com/~lynn/aadsm7.htm#rhose3 Rubber hose attack
https://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
https://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies

and specifically this post:
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007

also includes a reference to an article that "interchange fees" are the largest expense for C-stores, larger even than labor or any other item.

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 09:17:37 -0600
re:
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies

and for other drift, past posts mentioning acquiring financial institution
https://www.garlic.com/~lynn/aadsm2.htm#mcomfort Human Nature
https://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
https://www.garlic.com/~lynn/aepay3.htm#sslset1 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/aepay3.htm#x959luid X9.59 LUID comment resolution
https://www.garlic.com/~lynn/aepay4.htm#miscdns misc. other DNS
https://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#x915 Ballot for Withdrawal of X9.15 Posted - X9/01-LB#7-X9A/01-LB#3
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror13 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
https://www.garlic.com/~lynn/aadsm11.htm#0 Basic credit-card payment question
https://www.garlic.com/~lynn/aadsm11.htm#29 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#31 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm18.htm#15 In Search of Eve - the upper boundary on Mallory
https://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
https://www.garlic.com/~lynn/2000f.html#22 Why trust root CAs ?
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007h.html#32 sizeof() was: The Perfect Computer - 36 bits?

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 10:04:58 -0600
Andrew Swallow <am.swallow@btopenworld.com> writes:
There is a chance that independent programs may run on a multi-threaded machine, since they do not talk to each other they do not get in each others way. All I/O and requests for more ram would have to be via a single processor in the CPU. Windows would have to implement the locks to keep them apart. Debugging such locks is not easy.

multi-threaded has been used to refer to kernel/library support for application having multiple execution units ... i.e. POSIX threads reference
http://www-128.ibm.com/developerworks/linux/library/l-posix1.html

Nearly all DBMS implementations have made heavy use of multi-threaded operation ... being able to switch between transactions ... especially while waiting for transactions that are blocked/stalled performing disk operations.

more recently it has also been used for hardware implementations that emulate multiple processors when there is only a real single processor. the hardware scenario has been used to compensate for various things that stall the processor execution (say cache miss) ... allowing the processor to switch to another execution (emulated processor) that might not be stalled.

i've mentioned that this was worked on for 370/195 back in the 70s ... in part because most codes ran about half 195 peak processing rate (because of various processor stalls). having two processor "threads" running concurrently had a chance of keeping 195 running at peak processing thruput. recent reference
https://www.garlic.com/~lynn/2007i.html#45 IBM System/360 Model 85: The Bashful Computer

Charlie had invented the compare&swap instruction at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

when he was working on fine-grain kernel locking for cp67 multiprocessor support. there was some reluctance to include compare&swap in 370 architecture ... claiming that a purely multiprocessor instruction couldn't be justified. In order to get justification for compare&swap, uses had to be invented that weren't specifically multiprocessor oriented, recent reference
https://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation

as a result, the use of compare&swap for (software) multi-threaded (i.e. mainframe "multiprogramming") was invented. lots of past posts mentioning smp multiprocessor support and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp

Example uses for the compare&swap instruction were included in 370 Principles of Operation as programming notes. This programming notes now appear in the appendix of Principles of Operation ... recent reference:

A.6 Multiprogramming and Multiprocessing Examples
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03&DT=20040504121320

The "multiprogramming" examples show how compare&swap can be used to coordinate the operation of multiple threads w/o having to make calls into the kernel (eliminating the associated overhead of kernel calls).

You can have application (like DBMS) running multiple concurrent threads. If the operation is on a single-processor machine ... only one thread will happen to be running at any moment at time. However, if the operation is a real multiprocessor machine ... the application might have multiple threads running concurrently on the different processors.

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 10:15:37 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
Nearly all DBMS implementations have made heavy use of multi-threaded operation ... being able to switch between transactions ... especially while waiting for transactions that are blocked/stalled performing disk operations.

re:
https://www.garlic.com/~lynn/2007i.html#49 John W. Backus, 82, Fortran developer, dies

for a whole lot of topic drift ... many DBMS implementations also provide support for distributed operation and distributed lock operation ... i.e. processing across multiple processors that don't share physical memory.

some recent posts mentioning distributed DBMS operation and/or distributed lock operation
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#41 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006j.html#20 virtual memory
https://www.garlic.com/~lynn/2006o.html#32 When Does Folklore Begin???
https://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
https://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?
https://www.garlic.com/~lynn/2006x.html#18 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007c.html#42 Keep VM 24X7 365 days

some old posts mentioning some scale-up work with regard to distributed database and distributed locking
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15

and old email about working on scale-up work in distributed operation
https://www.garlic.com/~lynn/lhwemail.html#medusa

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 10:29:20 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
I *refuse* to use a debit-card; because unlike a credit-card, anybody with the number can *drain your entire account*; and you have no recourse! Debit cards don't have the government mandated protections that credit-cards do. Besides, there are many cases where you need *cash*; credit-cards, debit-cards, or checks NOT being accepted.

for some topic drift ... a lot of the newer debit cards have a card association "bug" on them ... and can be used as "signature debit" w/o requiring PIN/number. These days, you usually have to specifically ask for a debit card that is "PIN-debit" only that can't (also) be used in "signature debit" mode (and doesn't have a card association "bug"), aka can only be used in PIN-debit mode.

the "signature debit" issue also came up in the walmart class-action anti-trust suit against the card association. recent posts
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies

other past posts mentioning signature debit operation
https://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
https://www.garlic.com/~lynn/aadsm9.htm#cfppki2 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
https://www.garlic.com/~lynn/aepay10.htm#10 InfoSpace Buys ECash Technologies
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005u.html#14 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006u.html#48 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 12:06:39 -0600
Bernd Felsche <bernie@innovative.iinet.net.au> writes:
Every day that I visit a customer site, I see otherwise intelligent people drop 20 IQ points as they face up to their "workstation". Others give up completely and lean very heavily on "support" to get even the most trivial tasks completed.

and now for something different:

Tricky spelling drains the brain
http://www.newscientist.com/article/dn11731-tricky-spelling-drains-the-brain.html

from above:
Spelling tricky words -- such as "yacht" -- is no day at the beach, it seems. New brain-scan images have shown how our minds struggle when the sound of the word does not closely match its spelling.

... snip ...

How plastic is your brain? UH engineer seeks answers
http://www.physorg.com/news96911031.html

from above:
It may seem easy to change your mind, but if it's your brain we're talking about, maybe it's harder than we think. A University of Houston professor is looking into this with research into something called 'brain plasticity.'

... snip ...

and of course ... recent topic drift into arena of complexity
https://www.garlic.com/~lynn/2007i.html#44 latest Principles of Operation

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 12:10:28 -0600
pechter@pechter.dyndns.org (William Pechter) writes:
After watching Tempest testing... anyone who thinks that wireless Lans will ever be completely secure is nuts. If it radiates signals it can be cracked.

and for little topic drift (with TEMPEST mention):
https://www.garlic.com/~lynn/2007h.html#58 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#63 T.J. Maxx data theft worse than first reported

including reference in the above to

Laptops And Flat Panels Now Vulnerable to Van Eck Methods
http://hardware.slashdot.org/hardware/07/04/20/2048258.shtml
Seeing through walls
http://www.newscientist.com/blog/technology/2007/04/seeing-through-walls.html

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 13:59:33 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
Nearly all DBMS implementations have made heavy use of multi-threaded operation ... being able to switch between transactions ... especially while waiting for transactions that are blocked/stalled performing disk operations.

re:
https://www.garlic.com/~lynn/2007i.html#45 IBM System/360 85: The Bashful Computer
https://www.garlic.com/~lynn/2007i.html#49 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#50 John W. Backus, 82, Fortran developer, dies

and for other drift ... there is some correspondence between application stalls ... waiting for disks ... and processor stalls (on cache miss) waiting for main memory.

in the late 70s, I had started making comments about relative system disk thruput declining by an order of magnitude over more than a decade. Some disk division executives didn't appreciate the comment and assigned the performance & modeling group to refute the statement. After a couple weeks they came back and observed that I had slightly understated the problem. Part of this was apparent from all the work on dynamic adaptive resource management ... and a subpart of it that I called scheduling to the bottleneck ... aka part of dynamic adaptive resource management was identifying major system thruput bottlenecks (and same code could reasonably adapt across a wide-range of configuration as well as computer technology over periods of years or decades). The relative thruput of various system components had changed since the late 60s when I had first started work on dynamic adaptive resource management (and therefor the major system bottlenecks had also shifted). Some recent posts mentioning dynamic adaptive resource management:
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#7 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation
https://www.garlic.com/~lynn/2007i.html#46 Linux: The Completely Fair Scheduler

part of the compensation for the degrading relative system thruput of disks was to leverage the significant increases in real memory sizes for caching. part of this can be seen in the early 80s with the start in the update in relational DBMS. One of the things that System/R had done was eliminate the direct record pointer management (exposed as part of the paradigm that applications dealt with in the "physical" DBMS from the 60s) with indexes that were part of the underlying operation (implicit, automatically managed, and applications no longer had to directly deal with). The pros & cons ... the STL "60s" dbms people claimed that RDBMS typically doubled the physical disk requirements for a database (because of the space needed for the indexes) and drastically increased the number of physical I/Os (reading the indexes). The SJR, RDBMS people claimed that changing the exposed record pointer to implicit indexes significantly simplified the management, administration, and use of databases. lots of past posts mentioning system/r
https://www.garlic.com/~lynn/submain.html#systemr

Changes in the early 80s was significant increase in disk capacity and significant decrease in price per disk mbyte (mitigating the disk space for indexes issue) and the significant increase in real storage sizes that could be leveraged to cache the indexes (eliminating the significant physical disk i/o operations needing to read index records).

misc. recent posts mentioning system/r (and some of the trade-off issues changing between the 70s and 80s with regard to disks):
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007b.html#16 V2X2 vs. Shark (SnapShot v. FlashCopy)
https://www.garlic.com/~lynn/2007b.html#31 IBMLink 2000 Finding ESO levels
https://www.garlic.com/~lynn/2007b.html#58 Authentication architecture on a Unix Network
https://www.garlic.com/~lynn/2007c.html#42 Keep VM 24X7 365 days
https://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#27 modern paging
https://www.garlic.com/~lynn/2007d.html#37 MAC and SSL
https://www.garlic.com/~lynn/2007e.html#1 Designing database tables for performance?
https://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction
https://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object
https://www.garlic.com/~lynn/2007e.html#36 Quote from comp.object
https://www.garlic.com/~lynn/2007e.html#37 Quote from comp.object
https://www.garlic.com/~lynn/2007e.html#63 FBA rant
https://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
https://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology
https://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology
https://www.garlic.com/~lynn/2007f.html#54 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007f.html#66 IBM System z9
https://www.garlic.com/~lynn/2007g.html#25 Bidirectional Binary Self-Joins
https://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings

misc. past posts observing the change in primary/major system thruput bottlenecks over period of some decades:
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
https://www.garlic.com/~lynn/98.html#46 The god old days(???)
https://www.garlic.com/~lynn/99.html#4 IBM S/360
https://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
https://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
https://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
https://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
https://www.garlic.com/~lynn/2002.html#5 index searching
https://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
https://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
https://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
https://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
https://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After Multi-Core?

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 14:27:42 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
There are banks that offer "Totally Free Checking". I'd suggest looking into one of them. I did about ten years ago when my 1st National account started sticking on more and more charges for things I hadn't been paying for before.

there was something of a brouhaha that went on with the e-check (electronic check) trials by FSTC in the 90s
http://www.fstc.org

the issue was that customers having gotten use to "free" amd weren't easily going to give it up. the problem is that nothing is free, financial transactions cost ... in people time, infrastructure operations, computers, etc. ... i.e. earlier reference to analysing summary of financial institution operational costs
https://www.garlic.com/~lynn/2007e.html#65 Securing financial transactions a high priority for 2007

So the financial institution had to be able to cover the cost in some manner ... things like difference between what was being credited to the account for interest and what the financial institution was able to earn on the money in the account (it bears a little resemblance to crooks saying stealing money from insurance companies doesn't actually hurt anybody ... the money has to come from someplace ... it doesn't materialize out of thin air).

So the choices were to carry the e-check thru

1) the debit network, transaction is immediate, tends to be ISO8583 standard network ... similar to credit network (and sometimes they can use the same terminals at point-of-sale)

2) the ACH network, transaction can take 24-48 hrs to "clear".

Now, in the checking world, there is this thing called "float" ... the difference between the date of the check and when the check actually clears/settles. "Float" is one of the places that financial institutions can recover money to help underwrite the costs of their (especially checking) operations.

So many of the financial institutions wanted e-check to operate thru the ACH network ... where there is some float ... as opposed to the debit network ... where there effectively is no float.

for additional drift ... x9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959
and old mapping x9.59 transactions to iso8583
https://www.garlic.com/~lynn/8583flow.htm

past posts mentioning financial, banks, transactions etc in this thread:
https://www.garlic.com/~lynn/2007h.html#76 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#0 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#9 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#12 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#41 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 15:13:44 -0600
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
No, you have to have an account and pay money to get all of it. I just talked to a guy who did ING Direct's online account offerings: it grabbed all the data available on US customers and came up with the top twenty offers to make them, then heuristically pruned them to choose the best offer. Paid for itself in a month and they had to stop using it as their back office couldn't keep up with the demand generated.

same time we were called into consult with small client/server startup that wanted to do payments on their server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
and part of it was this thing called payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway
the whole thing frequently now called electronic commerce

....

we were also asked to consult on designing a targeted market offering based on recent 15-18month credit transactions ... i.e. rather than use demographics to guess at buying habits ... it was using buying habits to guess at buying habits. the thing was also being audited by dozen or so different privacy organizations ... to guarantee that nobody's privacy was violated in making/determining the target market offerings. the initial pass involved a small pilot with something like 60mil accounts and something like 1.5million transactions per day ... being able to scale up to something like ten times as many accounts and possibly 20 times as many transactions per day (peak buying season). scale-up was an interesting issue.

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 15:43:29 -0600
re:
https://www.garlic.com/~lynn/2007i.html#55 John W. Backus, 82, Fortran developer, dies

a little more topic drift about financial infrastructure costs

slightly related recent posting here
https://www.garlic.com/~lynn/2007i.html#56 John W. Backus, 82, Fortran developer, dies

mentioning having consulted with small client/server startup wanting to be able to do payment transactions

... we also were asked to do operational system design and the operational costing (i.e. what would the costs be to operate such a service) for DEC's millicent ... a little topic drift from the same organization that brought you altavista ... some millicent refs:
http://www.cs.newcastle.edu.au/Research/MSEG/visual/millicent/milli.html
http://www.soe.ucsc.edu/~abadi/Papers/millicent.html
http://www.xent.com/FoRK-archive/winter96/0690.html
http://www.jerrypournelle.com/slowchange/Millicent.html

as well as a similar task (design & cost) for deploying MONDEX in the states.

some old posts mentioning mondex
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/aadsm18.htm#42 Payment Application Programmers Interface (API) for IOTP
https://www.garlic.com/~lynn/aadsm20.htm#7 EMV
https://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm23.htm#23 Payment systems - the explosion of 1995 is happening in 2006
https://www.garlic.com/~lynn/aadsm25.htm#31 On-card displays
https://www.garlic.com/~lynn/2002e.html#14 EMV cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002g.html#53 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2002g.html#54 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
https://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure?
https://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless)

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 28 Apr 2007 18:28:14 -0600
"Robert" <sabu77@comcast.net> writes:
Not true. Many banks, including mine, make you not responsible for false charges on your debit card. Visa debit cards are protected.

this website
http://www.uspirg.org/ who they are:
http://www.uspirg.org/about-us

has a little more explanation on this site about debit cards (what they say and what they have to do, or actually do, may not be the same)
http://www.pirg.org/consumer/banks/debit/debitcards1.htm

discussion here:
http://www.in.gov/dfi/education/Money_Smart/debit_cards.htm

FTC website:
http://www.ftc.gov/bcp/conline/pubs/online/payments.shtm

from above:
For debit: The EFTA applies to electronic fund transfers -- transactions involving automated teller machines (ATMs), debit cards and other point-of-sale debit transactions, and other electronic banking transactions that can result in the withdrawal of cash from your bank account.

Lost or stolen debit cards: If someone uses your debit card, or makes other electronic fund transfers, without your permission, you can lose from $50 to $500 or more, depending on when you report the loss or theft. If you report the loss within two business days after you discover the problem, you will not be responsible for more than $50 for unauthorized use. However, if you do not report the loss within two business days after you realize the card is missing, but you do report its loss within 60 days after your statement is mailed to you, you could lose as much as $500 because of an unauthorized withdrawal. And, if you do not report an unauthorized transfer or withdrawal within 60 days after your statement is mailed to you, you risk unlimited loss. That means you could lose all the money in your account and the unused portion of your maximum line of credit established for overdrafts.

Some financial institutions may voluntarily cap your liability at $50 for certain types of transactions, regardless of when you report the loss or theft; because this is voluntary, their policies could change at any time. Ask your financial institution about its liability limits.

EFT errors: The EFTA's error procedures apply to certain problems. This can include:

• electronic fund transfers that you -- or anyone you've authorized to use your account -- have not made; • incorrect electronic fund transfers; * omitted electronic fund transfers; • a failure to properly reflect electronic fund transfers; and • electronic fund transfers for which you request an explanation or documentation, because of a possible error.

To take advantage of the EFTA's error resolution procedures, you must notify your financial institution of the problem not later than 60 days after the statement containing the problem or error was sent. Although most financial institutions have a toll-free number to report the problem, you should follow-up in writing. For retail purchases, your financial institution has up to 10 business days to investigate after receiving your notice of the error. The financial institution must tell you the results of its investigation within three business days of completing its investigation. The error must be corrected within one business day after determining the error has occurred. If the institution needs more time, it may take up to 90 days, in many situations, to complete the investigation -- but only if it returns the money in dispute to your account within 10 business days after receiving notice of the error, while it reviews your concerns.


... snip ...

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 29 Apr 2007 18:32:02 -0600
"Robert" <sabu77@comcast.net> writes:
My bank and many others do not make you responsible for debit card losses, especially Visa debit cards. The above information is true only for some other banks.

re:
https://www.garlic.com/~lynn/2007i.html#58 John W. Backus, 82, Fortran developer, dies

i.e. as in previous references ... financial institutions charge significantly more for signature-debit than pin-debit (through the higher fees that they can charge merchants) ... even though signature-debit fraud & related infrastructure cost is significantly higher than pin-debit

Study: Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit
http://www.digitaltransactions.net/newsstory.cfm?newsid=738

effectively being able to recover all expenses from the merchants in the interchange fees charged (aka at the same time signature-debit has more fraud and is more costly infrastructure while also being more profitable for financial institutions). since this is so profitable for the financial institutions ... it makes sense that they would attempt to minimize consumer fears about using signature-debit (by advertising significant safety ... in excess of what gov. regulations may require, although as pointed out in the Federal Trade Commission article ... this may not continue to be true; aka "could change at any time").
http://www.ftc.gov/bcp/conline/pubs/online/payments.shtm and
http://www.pirg.org/consumer/banks/debit/debitcards1.htm

i.e. from above
Debit cards make banks a lot of money. When you use the card like a credit card (with a signature, but not with a PIN), banks take a hefty fee from the merchant.

... snip ...

and article making the inverse statement about fraud

Study: PIN Debit Cheaper, Less Fraud-Prone Than Signature
http://www.digitaltransactions.net/newsstory.cfm?newsid=768

the significant costs to the overall infrastructure, related to signature-debit, appeared to have been at least part of the motivation for the walmart class-action anti-trust suit against the associations
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies

other posts in this sub-thread:
https://www.garlic.com/~lynn/2007h.html#76 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#0 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#12 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#41 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#55 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#57 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#58 John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 29 Apr 2007 19:23:24 -0600
Peter Flass <Peter_Flass@Yahoo.com> writes:
OS/2 apps are extensively threaded, and it causes remarkably few problems.

from long ago and far away

Date: Fri, 4 Dec 87 15:58:10 est
From: wheeler
Subject: os2 dispatching

fyi ... somebody in boca sent a message to endicott asking about how to do dispatch/scheduling (i.e. how does vm handle it) because os2 has several deficiencies that need fixing. VM Endicott forwarded it to VM Kingston and VM IBM Kingston forwarded it to me. I still haven't seen a description of OS2 yet so don't yet know about how to go about solving any problems.


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

Date: Fri, 4 Dec 87 15:53:29 est
From: wheeler
To: somebody at bcrvmpc1 (i.e. internal vm network node in boca)
Subject: os2 dispatching

I've sent you a couple things that I wrote recently that relate to the subject of scheduling, dispatching, system management, etc. If you are interested in more detailed description of the VM stuff, I can send you some descriptions of things that I've done to enhance/fix what went into the base VM system ... i.e. what is there now, what its limitations are, and what further additions should be added.


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

and ...
os/2 timeline starting dec87
http://pages.prodigy.net/michaln/history/timeline.html
os2 release 1 starting dec87
http://pages.prodigy.net/michaln/history/os210/index.html
os/2 timeline starting dec87 (with some prehistory)
http://www.os2bbs.com/os2news/OS2History.html
os/2 timeline starting dec87 (with some prehistory)
http://www.millennium-technology.com/HistoryOfOS2.html

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 07:56:53 -0600
Bernd Felsche <bernie@innovative.iinet.net.au> writes:
kill -9 is suicide for data integrity and resource management.

Application-based resource management has not chance to clean up which can leave stuff like shared memory and semphores allocated, perhaps preventing other processes from doing their thing.

It is in many cases safer to use the BRS.

And I do that when the usual signals (SIGTERM, SIGHUP, SIGINT and SIGFPE) don't work on e.g. RDBMS engines and processes.


long ago and far away ... i created shell function definition that did a ps -ef, grep'ed on a specified argument and did a kill -9 on the results (which i periodically still use)

one of the definitions for being a DBMS ... relational or otherwise ... is supporting transactions and commits ... that there should be no inconsistencies regardless of how/where failure has occurred.

lots of past posts on original relational/sql implementation (and well as possibly some number of other dbms related activities)
https://www.garlic.com/~lynn/submain.html#systemr

some number of past posts on doing high availability product (and/or distributed lock manager in support of transactions and commit infrastructures)
https://www.garlic.com/~lynn/subtopic.html#hacmp

one of the issues in distributed lock manager ... was not only cleanup after some process glitch in single CEC environment (i.e. single processor or multiple processors in SMP/shared memory environment), but cleanup in distributed environment involving potentially large number of distributed and/or clustered CECs

specific meeting discussing some of the issues
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15

and some references to availability specific items
https://www.garlic.com/~lynn/submain.html#available

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 07:44:42 -0600
jmfbahciv writes:
I was thinking about that piece of GM's business that did all the financing when somebody bought their car and borrowed from them.

re:
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies

that is different part of the business. some of the automobile companies (and other companies) have bought up an ILCs that had been grandfathered from one or another of the national banking legislation. the issue for financing/lending, either a national banking charter was required (or one of the grandfathered ILCs) ... or the company had to apply and obtain a state banking charter in every one of the states ... which could be extremely costly and time-consuming (it was much simpler to have a single bank charter to operate nationally than having 50 separate ones in each of the states).

there have been analysis that possibly (for some operations), nearly all the profit comes from financing the loan ... rather than selling of the car (jokes about cars just being an excuse for making the loan).

public key password authentication

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key password authentication
Newsgroups: sci.crypt
Date: Mon, 30 Apr 2007 08:10:44 -0600
Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:
Are there useful and efficient password auth methods where the server admin, possessing a user's server-side secret and a log of his auth sessions, will not learn how to authenticate as the user?

there original kerberos pk-init draft ... simply allowed for registering a public key in lieu of a password. the server then presented some random data to the client ... which was digitally signed ... and the server verified the digital signature with the on-file public key. public/private key operation basically is countermeasure to replay attacks i.e. presentation of static authentication data than can be evesdropped and replayed. Having the client digitally sign some server supplied random data is similarly a countermeasure to replay attacks (where the attacker evesdrops an digital signature that is always the same). the other characteristic of public/private key operation is that the information used to verify the digital signature isn't what is used to generate the digital signature.

now, depending on the public/private key technology chosen there can be a significant difference in the efficiency in the verifying of the digital signature.

it wasn't until later that pki and digital certificate based operation was addeded to kerberos pk-init operation ... along with all the additional complexity, overhead, and waste.

aka ... PKI and digital certificate paradigm is for the situation analogous to the letters of credit/introduction from the sailing ship days (and earlier) ... where the relying party has absolutely no prior knowledge of the stranger that they are dealing with ... and absolutely no other means of obtaining that information. By definition, if the client has to (pre)register anything with the server ... it invalidates the assumptions justifying the complex PKI operations and making the digital certificates redundant and superfluous.

lots of past posts mentioning kerberos pk-init
https://www.garlic.com/~lynn/subpubkey.html#kerberos

the other widely deployed and prevalent authentication infrastrature found in the internet world is radius ... and there have been similar simple definitions/implementations for radius ... where a public key is simply registered in lieu of a password
https://www.garlic.com/~lynn/subpubkey.html#radius

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 09:42:33 -0600
Charlton Wilbur <cwilbur@chromatico.net> writes:
For me to charge something on my credit card, I need to provide the credit card number and some bit of personally identifying information to the vendor. The vendor is not supposed to keep that information any longer than necessary to process the charge, but TJX did.

Keeping the information safely in my wallet and not giving it to TJX means I can't buy anything from TJX. This may be wise, but it hardly counts as "online banking."

In short, to do any kind of transaction, you need to provide information to the entity you're doing business with. This was true in the days of entirely paper checks, because the account number was written on the check. If you don't provide that information, you don't do business.


there is some indication that the corporate payment transaction concentrator was hacked ... and attackers skimmed the information as it passed to the payment network ... aka instead of every card-swipe terminal doing its own dialing to 1-800 number to exchange transaction with the payment network ... a corporate routes all the POS-terminal activity to a corporate transaction concentrator (frequently can eliminate the 10-30sec delay introduced my the modem dialing operation). a couple recent posts
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#58 T.J. Maxx data theft worse than first reported

in some sense ... a corporate payment transaction concentrator is similar to the original internet payment gateway that we worked on when we consulted for small client/server startup that wanted to do payment transactions on their servers (now frequently referred to as electronic commerce)
https://www.garlic.com/~lynn/subnetwork.html#gateway

merchants are also placed in something of untenable situation ... needing to retain information for an extended period in order to handle any disputes ... slightly related old post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

in part, the whole PCI stuff revolves around rules and specifications for hiding/protecting the information that merchants have to retain in order to perform normal business operations.

and more recent posts observing that the attackers can afford to possibly outspend defenders by as much as 100:1
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported

one of the things is that the existing infrastructure is extremely vulnerable to replay attacks ... aka using information from previous transactions to perform new, fraudulent transactions.

in the mid-90s, the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments (ALL, as in point-of-sale, credit, debit, face-to-face, ACH, check, internet, stored-value ... aka ALL). the result was x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

one of the things that x9.59 addressed was eliminating the vulnerability to replay attacks. it didn't do anything with regard to hiding/encrypting/protecting information from previous transactions ... it just made that information useless to attackers for performing fraudulent transactions (aka nearly totally eliminating the risk from replay attacks and the use of information from previous transactions in performing new, fraudulent transaction).

related posts on existing payment infrastructure being vulnerable to replay attacks
https://www.garlic.com/~lynn/subintegrity.html#payments

lots of past posts about harvest/skimming of information from existing/previous transactions
https://www.garlic.com/~lynn/subintegrity.html#harvest

some number of past posts about shared-secret (authentication) based paradigms (and vulnerability to replay attacks and/or impersonation)
https://www.garlic.com/~lynn/subintegrity.html#secrets

recent post about replay attack vulnerabilities in authentication paradigms
https://www.garlic.com/~lynn/2007i.html#63 public key password authentication

lots of past posts mentioning general topic of threats, vulnerabilities, fraud, attacks, and/or exploits
https://www.garlic.com/~lynn/subintegrity.html#fraud

and to take it from a slightly different viewpoint ... past posts on assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 10:58:49 -0600
Charlton Wilbur <cwilbur@chromatico.net> writes:
But this is not the sort of thing that keeping the information at home will solve. You have to hand over the information to the merchant, and the merchant has to hand it over to the credit card processing network. This problem cannot be solved by improving home firewalls.

re:
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies

for a little recent topic drift
https://www.garlic.com/~lynn/aadsm26.htm#64 Dr Geer goes to Washington

in any case, that was what we did in the x9a10 financial standard working group in doing detailed study of the end-to-end threats and vulnerabilities.

we had been asked to come in and consult with the small client/server startup that wanted to do payment transactions ... and they had this technology called SSL. SSL was used in hiding the transaction while it was "in flight" thru the internet (hiding the information).

we then did some work in the x9a10 financial standard working group that in the mid-90s which had been given the reguirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 financial standard protocol for *ALL* retail payments
https://www.garlic.com/~lynn/x959.html#x959

i.e. some amount of our earlier work on SSL and payments was obsoleted by our work on X9.59 financial standard protocol

one of the things that we observed was that the earlier payment transaction work (that is commingly now referred to as electronic commerce) involving hiding the information was now redundant and superfluous ... i.e. from the security acronym PAIN:

the existing electronic commerce infrastructure, using SSL to hide the information, was made obsolete with x9.59. Instead of using "privacy" (aka confidentiality, hiding, etc) to obtain security; x9.59 protocol uses authentication and integrity to obtain security.

part of this was that doing detailed look at the end-to-end threats and vulnerabilities ... we found numerous instances where the data was at rest and was subject to attacks by both insiders and outsiders.

in the past, we observed that even if the planet was buried under miles of (information hiding) encryption ... it still wouldn't be able to prevent information leakage out of the existing infrastructure. Part of the reason is that information from existing transactions can be used in replay attacks for fraudulent transactions. As a result, the information has to be kept confidential and never divulged (not to yourself, not to the merchant, not to your financial institution, not to anybody). On the other hand, the same information is required in dozens (of ongoing) standard business processes. As a result the same information (that has to be kept confidential and never divulged) has to be also readily available for the scores of business processes where it is required.

misc. past posts mentioning that burying the planet under miles of encryption isn't the solution:
https://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
https://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
https://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
https://www.garlic.com/~lynn/aadsm26.htm#24 News.com: IBM donates new privacy tool to open-source Higgins
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL ... addenda
https://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006p.html#8 SSL, Apache 2 and RSA key sizes
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2006w.html#32 'Innovation' and other crimes
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#33 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007d.html#34 Mixed Case Password on z/OS 1.7 and ACF 2 Version 8
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 11:46:30 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
we had been asked to come in and consult with the small client/server startup that wanted to do payment transactions ... and they had this technology called SSL. SSL was used in hiding the transaction while it was "in flight" thru the internet (hiding the information).

we then did some work in the x9a10 financial standard working group that in the mid-90s which had been given the reguirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 financial standard protocol for *ALL* retail payments
https://www.garlic.com/~lynn/x959.html#x959

i.e. some amount of our earlier work on SSL and payments was obsoleted by our work on X9.59 financial standard protocol


re:
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#65 John W. Backus, 82, Fortran developer, dies

somewhat in the wake of the stuff now commonly called electronic commerce, there were a number of other efforts in the mid-90s to also look at enhancing transactions (besides the x9a10 standards work).

misc. posts on the payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway
and slightly related background
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

i.e. two of the people in this meeting
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
from ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

were now responsible for something called commerce server.

most of the other efforts were targeted at some particular, specific point solution ... were not bothering to do detailed end-to-end threat and vulnerability analysis ... and not looking at coming up with comprehensive solution that addressed everything.

one of the things that was commonly mentioned in the mid-90s ... was that the hardware token solutions were extremely expensive and in order to introduce any sort of hardware token (as part of a solution) there might have to be (significant) compromises made in order to produce a cost effective solution.

it was in this time-frame that i would make my semi-facetious statement about taking a $500 mil-spec piece, and aggresively cost-reducing it by two to three orders of magnitude while at the same time, improving its security (i.e. not compromising).

the other objective/requirement was allow it to meet transit power and elapsed time requirements. transit was transition to contactless operation at various transit gates (subways, trains, metro, etc) and also had elapsed time-requirements of a hundred or two milliseconds at the transit gates.

now, one of the things that some of the other solutions looked at to decrease elapsed time with hardware tokens were doing certain operations in parallel ... by adding a whole bunch of parallel circuits ... and also drastically increasing the power draw ... far in excess of what could be done in a timely manner with contactless chips (drawing power thru the air from the reader or transit gate).

the alternative was to come up with an equally secure solution that required enormously fewer electrons to achieve the same goal (i.e. product of electron flow rate and elapsed time) ... and be able to implement it in a secure hardware package with possibly a three orders of magnitude cost reduction.

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 13:18:50 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
now, one of the things that some of the other solutions looked at to decrease elapsed time with hardware tokens were doing certain operations in parallel ... by adding a whole bunch of parallel circuits ... and also drastically increasing the power draw ... far in excess of what could be done in a timely manner with contactless chips (drawing power thru the air from the reader or transit gate).

the alternative was to come up with an equally secure solution that required enormously fewer electrons to achieve the same goal (i.e. product of electron flow rate and elapsed time) ... and be able to implement it in a secure hardware package with possibly a three orders of magnitude cost reduction.


re:
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#65 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#66 John W. Backus, 82, Fortran developer, dies

for more topic drift ... various of the hardware-related security solutions based on (relative) big honking power consumption also tended to be vulnerable to attacks related to measuring and profiling their power consumption

going to a hardware-related security with totally different and significantly reduced power utilization also eliminated such attacks (somewhat intertwined with doing aggressive simplification and cost reduction)
https://www.garlic.com/~lynn/x959.html#aads

A tribute to Jim Gray

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: A tribute to Jim Gray
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 14:02:25 -0600
A tribute to Jim Gray
http://www.theregister.com/2007/04/30/jim_gray_tribute/

recent posts mentioning Jim:
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007d.html#4 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#8 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007d.html#33 Jim Gray Is Missing
https://www.garlic.com/~lynn/2007g.html#28 Jim Gray Is Missing

How the Internet took over

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: How the Internet took over
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 14:09:30 -0600
How the Internet took over
http://news.yahoo.com/s/usatoday/20070430/tc_usatoday/howtheinternettookover

from above:
Twenty-five years ago the Internet as we now know it was in the process of being birthed by the National Science Foundation. Since then it's been an information explosion. From e-mail to eBay, communication and shopping have forever changed.

... snip ...

other email from the period about internet highspeed backbone and other operational considerations
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

recent posts making mention that while tcp/ip was technology basis for the internet, the nsfnet backbone was the operational precursor to the modern internet:
https://www.garlic.com/~lynn/2007b.html#5 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#43 Is computer history taugh now?
https://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip
https://www.garlic.com/~lynn/2007i.html#40 Best practices for software delivery

illegal aliens

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: illegal aliens
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 14:20:22 -0600
Al Balmer <albalmer@att.net> writes:
Even if your judgment of their bias is true, it's irrelevant. Biased sources can conduct unbiased studies. The data comes from the Census Bureau, the OMB, the Congressional Research Service, the INS, etc. and the methodology is presented. Rather than assumptions about bias, criticize the report itself:
http://www.cis.org/articles/2004/fiscal.html


re:
https://www.garlic.com/~lynn/2007i.html#18 John W. Backus, 82, Fortran developer, dies

In the above posting, I also made note of the CIS report (that used 2000 census information) ... but also found/noted an earlier GAO report that was very similar.

Free Checking

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Free Checking
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 17:23:54 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
We've been using ours for over 15 years now; and the bank-offer looks about the same today as it did when we signed on. The only difference being that we (deliberately) moved from "Totally Free Checking" to "55+ checking" about 8 years ago when I turned 55; because they had the same benefits, PLUS they pay a minuscule amount of interest on money in the checking account. Only a few pennies a month, but it beats *no* interest. When you borrow money from *them* however ... Watch your wallet.

US financial institutions are earning nearly 40percent of their bottom line from payments ... compared to ten percent for European institutions.

post from last year
https://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems

much of that coming from fees charged merchants. recent reference
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies

Free Checking

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Free Checking
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2007 18:45:46 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
That "Fees Charged Merchants" part, is mainly things like what they charge for using Credit Cards, I'm fairly sure.

Many merchants would rather have the bank skim off a certain percentage of the take, just to be sure they get paid. On the other hand, some won't take credit-cards because they want the whole pile. So, you get two merchants right next to each other; and one doesn't take checks but does take credit-cards; while the other takes credit-cards but doesn't take checks. And each has good justification for doing-so.


re:
https://www.garlic.com/~lynn/2007i.html#71 Free Checking

a lot of merchants will subscribe to some sort of check validation and/or guarantee function (you can see the decals on the register or windows ... next to the card association brands). check validation ... indexed by drivers license # will be somewhat less than card interchange fees. check guarantee can be larger than card interchange fees (i.e. the guaranteeing organization will pay the merchant and take responsibility for what happens if the check doesn't clear or bounces).

the issue for some merchants is cash flow ... they have bills to pay related to goods sold consumers ... and if they have trouble collecting from merchants, it can but them into real cash flow bind.

note thhat there is also "shrinkage" for cash (for some merchants like fastfood operations, it can be pretty significant)... i.e. the difference between what is taken in at the till and what actually is net deposit at the bank. old post mentioning shrinkage
https://www.garlic.com/~lynn/2005u.html#14 AMD to leave x86 behind?

on the other hand ... the interchange fee as flat charge per transaction plus percent of transaction can be significant for merchants ... recent post mentioning that for c-stores ... card interchange fees is their single largest expense ... larger than labor or any other item.
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies

that may also account for some of the motivation behind the class-action anti-trust suit (which would imply that they all aren't happy with the state of interchange fees) ... there have also been a number of items in the last several weeks about continued push about looking at interchange fees

recent posts mentioning class-action anti-trust:
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies

some recent articles mentioning interchange fees

Retailers Urge State Efforts on Credit Card Interchange Fees
http://www.paymentsnews.com/2007/04/retailers_urge_.html
Payments Upstart GratisCards Aims to 'Eliminate' Interchange
http://www.digitaltransactions.net/newsstory.cfm?newsid=1285
The Corrosive Siege Over Signature-Card Interchange
http://www.digitaltransactions.net/newsstory.cfm?newsid=1223
Congressional Committee talks tough on interchange fees
http://www.finextra.com/fullstory.asp?id=16433
EC Report Criticizes Interchange Rates
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=117033394619412597249&block= EU competition commission eyes Visa interchange fees
http://www.finextra.com/fullstory.asp?id=16540
Has interchange hype brought us to the brink of a surcharging sea change?
http://aneace.blogspot.com/2006/06/has-interchange-hype-brought-us-to.html

public key password authentication

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key password authentication
Newsgroups: sci.crypt
Date: Mon, 30 Apr 2007 18:54:58 -0600
Mike Amling <nospam@nospam.net> writes:
But if the client has information beyond the password that the server does not have, for example, a private key protected by the user's password, then an attacker (who may be the server admin) with the corresponding public key but not the ciphertext containing the private key will find dictionary attack infeasible (assuming reasonable public/private key parameters). The authentication protocol may then be, for example, a zero knowledge proof of possession of the private key.

re:
https://www.garlic.com/~lynn/2007i.html#63 public key password authentication

there can be a separate kind of vulnerability against some public/private key infrastructures ... the issue is some operations have also looked at equated digital signatures (on documents and other things) ... as equivalent to human signatures (i.e. intent, implying having read, understood, agrees, approves, and/or authorizes) ... something that digital signatures were never designed to do ... but happens possibly because of semantic confusion generated because both "digital signatures" and "human signatures" both contain the word "signature"

this can be a dual-use attack ... when somebody at a server site ... instead or random data to be digital signed for authentication (countermeasure to replay attacks) transmits some sort of valid document. the exposure is, in part, because the majority of the authentication protocols will automatically digitally signed the transmitted "random data" w/o allowing the human to ever examine the contents.

some past posts discussing dual-use attack against digital signature infrastructures that attempt to extend it to be equivalent to human signature ... something that it was never intended to do:
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm26.htm#63 Public key encrypt-then-sign or sign-then-encrypt?
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
https://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
https://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006s.html#34 Basic Question

public key password authentication

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: public key password authentication
Newsgroups: sci.crypt
Date: Wed, 02 May 2007 06:43:07 -0600
Mike Amling <nospam@nospam.net> writes:
That's one reason to prefer a ZK proof of possession of the private key, over the signing of "random data".

re:
https://www.garlic.com/~lynn/2007i.html#63 public key password authentication
https://www.garlic.com/~lynn/2007i.html#73 public key password authentication

because it is technically better ... and/or lacking the word "signature" it avoids the semantic confusion introduced with the use of the term "digital signature"?

one of the scenarios in x9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959

was to have the digital signature applied to the transaction ... supplying both integrity and authentication on the transaction ... and not bothering to get confused about intent, and/or human having read, understood, agrees, approves, and/or authorizes ... for some topic drift ... misc. past posts about having been brought in to help word-smith cal. state (and then federal) electronic signature legislation
https://www.garlic.com/~lynn/subpubkey.html#signature

one of the issues in x9.59 financial standard protocol was to provide the integrity and authentication on the transaction itself ... avoiding potential (vulnerability and threat) cracks introduced into business processing infrastructure when authentication and integrity are done separately ... some amount of discussion in past posts about naked transaction metaphor ....
https://www.garlic.com/~lynn/subintegrity.html#payments

i.e. when the two operatons are performed separately (if the trouble is taken to both at all) and opportunities like MITM-attacks are introduced
https://www.garlic.com/~lynn/subintegrity.html#mitm

of course, the dual-use attacks, where the same private key is used to both sign "random data" ... for "authentication" only protocol ... and sign "non-random data" ... for both/combined integrity and authentication can create some ambiguity. the dual-use attack may come into play w/o even (totally) falling into the semantic confusion regarding the word "signature".

Part of the issue could purely be when the same digital signature private key is used for both purely "authentication" purposes (i.e. the automatic signing of random data) as well as used for combined "integrity" and "authentication" purposes as one operation (signing of non-random data ... and/or data with meaning) ... and people still getting confused that "integrity" also implies intent ... or from the security PAIN acronym non-repudiation

the issue in x9.59 financial standard protocol is then how to just have "authentication" and "integrity" on the transaction (providing armoring for the transaction and not leaving it naked, introducing opportunities for things like MITM-attacks) ... w/o the "digital signature" also carrying the sense of intent and human having read, understood, agrees, approves, and/or authorizes. something additional is then needed to carry the sense of intent ... separate from the digital signature. And from the naked transaction methapor ... if the indication of intent isn't also integrated with the transaction ... that could also introduce threats and vulnerabilities ... like MITM-attacks.

Free Checking

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Free Checking
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2007 06:50:55 -0600
jmfbahciv writes:
No,no. That was "free checking" and there are tons of fees in that. Frank and I were discussion "Totally Free Checking" which is another package getting sold to consumers of banks.

and/or to take one of the lines from the recent references about "free" schools ... how is it actually being paid for?
https://www.garlic.com/~lynn/2007i.html#55 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#71 Free Checking
https://www.garlic.com/~lynn/2007i.html#72 Free Checking

aka ... it just means that it is paid for some other way. this has also been discussed in this ng in the past regarding "free" internet service old email mentioning NSFNET
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
... old (and not so old) posts mentioning NSFNET
https://www.garlic.com/~lynn/subnetwork.html#nsfnet
and lots of posts mentioning internet
https://www.garlic.com/~lynn/subnetwork.html#internet

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2007 08:00:31 -0600
jmfbahciv writes:
Then why would GM sell a cash cow?

re:
https://www.garlic.com/~lynn/2007i.html#62 John W. Backus, 82, Fortran developer, dies

in general ... for almost any large conglomerate ... there can be lots of different strategic and/or tactical reasons.

strategic may have to do with a lot of the stock market being emotional and/or fickle. in situation having two completely different kinds of operations ... with two different kinds of P/E ratios ... the lower P/E ratio business can have a significant downward pressure on the overall stock price. splitting into two separate corporations can result in much larger, total, aggregate stock value ... than having the stock listed as single company.

tactical might be some executive is about to leave/retire ... and their (last) annual bonus may be much bigger if they sell an operation ... even if such a sale doesn't make much long term business sense.

a frequent excuse given is to spin-off "non-core" businesses ... implying that executives have trouble given adequate focus when radically different kinds of operations are involved ... it is much easier to have a single kind of business and hire executives that are specifically skilled in that single kind of business. a variation on the same theme might be if an operation has a cash cow that is radically different from the other parts of the business ... that executives become lazy in operating the non-cash-cow business ... since they can still "make numbers" (based on the cash-cow business).

Sizing CPU

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Sizing CPU
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 02 May 2007 09:08:06 -0600
edjaffe@ibm-main.lst (Edward Jaffe) writes:
I agree that part of what I wrote is misleading because I was thinking about processor resource contention analysis when I wrote it. :-[

Overall processor utilization is -- as you've said -- calculated from dispatched-time and/or wait-time accumulators maintained by the PR/SM and MVS dispatchers (e.g., LCCAWTIM is maintained by the MVS dispatcher). But, it's also true that the monitors must still periodically "sample" and remember the values contained within those accumulators to be able to calculate the percentage busy over any given interval.


or at least periodically "checkpoint" (log/journal) the numbers.

for some topic drift ... the science center had done the
https://www.garlic.com/~lynn/subtopic.html#545tech

port of apl\360 to cms\apl ... this opened up the use of apl for more "real-world" problems ... since typical apl\360 operation limited workspace size to 16kbytes (or sometimes as much as 32kbytes) ... i.e. cms\apl workspace size could be nearly as big as the virtual address provided

recent posts ... about when people in armonk started using cambrige cp67 system for cms\apl to do business analysis and modeling
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?

apl was being used for a lot of things that spreadsheets are used for today.

the science center also did a significant amount of work on performance monitoring, performance tuning, workload profiling, system characterization that also evolved into things like capacity planning.

cms\apl (and cambridge cp67 system) was also picked up by the marketing sales organization for something called HONE
https://www.garlic.com/~lynn/subtopic.html#hone

which later transition to vm370 and apl/cms ... with majority of world-wide sales and marketing support being provided by APL applications under vm370. in the 70s there was transition where sales could not even enter a customer order that hadn't first been processed by a HONE "configurator" (application written in APL).

The science center APL, performance modeling and capacity planning work somewhat came together in a sophisticated computer modeling application written in APL. A version of this was made available to (worldwide) sales and marketing as the performance predictor. Sales/marketing people could enter customer workload, configuration, and performance data ... and ask "what if" questions about what happens (to computer performance and thruput) when there are changes to configuration and/or workload.

some other past posts mentioning benchmarking, workload profiling, performance monitoring and/or work on capacity planning.
https://www.garlic.com/~lynn/submain.html#bench

for some topic drift ... recent post about "joke" in the resource manager:
https://www.garlic.com/~lynn/2007i.html#43 Latest Principles of Operation

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2007 12:23:38 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
from long ago and far away

Date: Fri, 4 Dec 87 15:58:10 est
From: wheeler
Subject: os2 dispatching

fyi ... somebody in boca sent a message to endicott asking about how to do dispatch/scheduling (i.e. how does vm handle it) because os2 has several deficiencies that need fixing. VM Endicott forwarded it to VM Kingston and VM IBM Kingston forwarded it to me. I still haven't seen a description of OS2 yet so don't yet know about how to go about solving any problems.

... snip ...

From: wheeler
Date: Fri, 4 Dec 87 15:53:29 est
To: somebody at bcrvmpc1 (i.e. internal vm network node in boca)
Subject: os2 dispatching

I've sent you a couple things that I wrote recently that relate to the subject of scheduling, dispatching, system management, etc. If you are interested in more detailed description of the VM stuff, I can send you some descriptions of things that I've done to enhance/fix what went into the base VM system ... i.e. what is there now, what its limitations are, and what further additions should be added.

... snip ...


re:
https://www.garlic.com/~lynn/2007i.html#60 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#email871204
https://www.garlic.com/~lynn/2007i.html#email871204b

in the time frame we were doing ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp

we also spent some amount of time talking to the SCI people. After departing the employer where we had been doing ha/cmp ... somewhat related to
https://www.garlic.com/~lynn/lhwemail.html#medusa

we spent some amount of time talking to both Convex and Sequent ... who were both doing SCI-based multiprocessor (Convex doing 128-way using 64 boards from HP with two HP risc processors per board and Sequent doing 256-way using 64 boards with four intel processors per board).

The sequent people had been doing 16 and 32 way multiprocessors using intel chip for some time ... supported by their dynix flavor of unix. In that time-frame when we were talking to them about SCI 256-way ... they claimed that they had also been doing work on getting redmond operating systems working on their (existing) hardware ... and also claimed that essentially all multi-processor scale-up work done on redmond operating systems had come from their work.

More recently ... the claim is that multi-core is resulted in multi-processor requirements started to filter down into the standard desktop environments. At least for the past two yrs ... the hardware conference talking about multi-core chips (existing and/or planned in the future) have a real problem because the application software technology supporting parallelism hasn't changed significantly in the past 20 hrs. You see operating system support and some applications supporting "embarrassingly" parallel operations (i.e. like large dbms transaction oriented stuff) ... but you don't see any fundamental change in application programming technology for supporting parallelism.

a couple posts from last year on the multi-core and parallelism challenge in the wake of hotchips conference:
https://www.garlic.com/~lynn/2006p.html#3 processors of the future: super-computer-on-a-chip?
https://www.garlic.com/~lynn/2006p.html#55 PowerPC or PARISC?

it isn't a theme that is just limited to hotchips conference ... but shows up repeatedly at numerous other chip oriented conference (discussing potentially significant programming paradigm changes needed to take advantage of the significant increase in processing cores). In fact, I was at a chip conference a yr ago where one of the senior chip engineers gave a talk specifically about the software programming paradigm will have to significantly change in order to start taking advantage of large numbers of cores.

It also has shown up in various conferences discussing "CELL" chips ... which is not only multi-core of the same type of programming architecture ... but also includes multiple cores with different kinds of programming architecture.

recent article from yesterday:
Microsoft super sizes multi-threaded tripe
http://www.theregister.co.uk/2007/05/01/mundie_mundie/


from above:
Microsoft, to its credit, has multi-threaded the calculations in Office Excel 2007. But that's about where the credit ends.

Intel and AMD executives fail to hide their disappointment with Microsoft well on the multi-threaded software front.

During a speech last June, Intel SVP Pat Gelsinger said the following:

"A couple of years ago, I had a discussion with Bill Gates (about the multi-core products). He was just in disbelief. He said, 'We can't write software to keep up with that.'"

Gates ordered the Intel executive to keep pumping out faster product. "No, Bill, it's not going to work that way," Gelsinger informed him.


... snip ...

lots of past posts mentioning smp multiprocessor operation and/or compare&swap instructions
https://www.garlic.com/~lynn/subtopic.html#smp

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2007 13:24:44 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
a few/sample past posts mentioning 1990 census study that found half of high school aged graduates were functionally illiterate.

re:
https://www.garlic.com/~lynn/2007i.html#18 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#70 illegal aliens

by implication in the CIS and GAO studies and in various other studies ... where it is talking about one segment of society producing less economic benefit than what they cost ... there are some economic issues about how does the society make up the shortfall ... presumably by extracted economic value from segments of society that provide society significantly more economic benefit than they cost.

some topic drift with respect to possible segments of society that produce more economic benefit than they cost.

Study: China Leaps Forward In Advanced Tech Education
http://www.investors.com/editorial/IBDArticles.asp?artsec=17&artnum=2&issue=20070501

from above:
In a recent Duke University study, researchers said China is overtaking the U.S. and India in advanced engineering and technology graduates.

... snip ...

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2007 13:45:58 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
when we were doing ha/cmp product ... we didn't make much difference between lots of cheap servers and clusters ... from development and architectual design standpoint. it seems to mainly come from vendors pricing policies as opposed to any fundamental architectual difference
https://www.garlic.com/~lynn/subtopic.html#hacmp


re:
https://www.garlic.com/~lynn/2007i.html#22 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#27 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#61 John W. Backus, 82, Fortran developer, dies

one of the things that we had done while we were doing ha/cmp product was coin the terms disaster survivability and geographic survivability to differentiate from simple disaster/recovery
https://www.garlic.com/~lynn/submain.html#available

recent item
Premier 100 Spotlight Series: 5 Disaster Survival Tips from Northrop Grumman Lessons on disaster recovery -- and survival -- from the IT team at Northrop Grumman.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=288135


and for other topic drift
IBM gives SharePoint users Tivoli backup muscle The OEM deal targets SharePoint Portal Server 2003, SharePoint Server 2007
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9018461


from above:
IBM introduced its new Tivoli Storage Manager (TSM) for Microsoft SharePoint today, giving users of the popular Microsoft online collaboration tool access to new backup and recovery options. Adding to its appeal, the new Tivoli component will integrate with all of TSM Extended Edition server's data protection capabilities on the back end.

... snip ...

TSM had previously been called ADSM (before being renamed). ADSM grew out of CMSBACK that I had originally started work on in the late 70s ... reference here:
http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml

past posts mentioning working on backup/archive (for things like disaster/recovery)
https://www.garlic.com/~lynn/submain.html#backup
and some old CMSBACK email
https://www.garlic.com/~lynn/lhwemail.html#cmsback

illegal aliens

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: illegal aliens
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2007 14:00:29 -0600
Al Balmer <albalmer@att.net> writes:
Not so simple a calculation. Remember that they aren't paying any of the other payroll taxes.

when looking for additional GAO reports on the subject ... ran across what looks like annual GAO report (for the past couple yrs) on federal contractors not bothering to pay federal taxes (payroll, corporate, etc) ... to the tune of something like aggregate $10b/annum. Reports say that the problem occurs across the spectrum of all federal contractors (from janitors to military arms manufacturers). The reports go on to say that the problem would be relatively quickly corrected if congress would allow the federal gov. to take into account whether or not a contractor had previously paid their taxes ... when awarding new contracts and/or renewing old contracts.

Interrupts

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Interrupts
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2007 17:37:08 -0600
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
Heck, it's bad enough just on the Windoze boxes alone - I sometimes forget that I'm in KEDIT rather than LIST.COM, hit F3 to try to find the next occurrence of a string, and find myself back at the command prompt with all my changes in the bit bucket.

F3 convention for quit .... predates XEDIT (KEDIT being a XEDIT work-alike) ... back to when standard cms edit was first enhanced to support 3270 fullscreen mode (for display and input, commands/alterations were still on command line). EDGAR was the first cms 3270 editor that supported alterations/commands in the "display" area.

Then there were some number of internal fullscreen editors before XEDIT.

some posts (and old email) getting into middle of why wasn't one of the more mature internal fullscreen editors released as a product rather than the relatively new comer XEDIT.
https://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet (fwd)
https://www.garlic.com/~lynn/2003d.html#25 Which Editor
https://www.garlic.com/~lynn/2006n.html#55 The very first text editor
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
https://www.garlic.com/~lynn/2006u.html#61 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006y.html#4 Why so little parallelism?

and other old posts mentioning xedit:
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000d.html#17 Where's all the VMers?
https://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#17 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#18 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#22 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001k.html#44 3270 protocol
https://www.garlic.com/~lynn/2001k.html#46 3270 protocol
https://www.garlic.com/~lynn/2001m.html#22 When did full-screen come to VM/370?
https://www.garlic.com/~lynn/2001m.html#33 XEDIT on MVS
https://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
https://www.garlic.com/~lynn/2002h.html#58 history of CMS
https://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
https://www.garlic.com/~lynn/2003.html#62 Card Columns
https://www.garlic.com/~lynn/2003d.html#22 Which Editor
https://www.garlic.com/~lynn/2003e.html#29 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#75 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2004o.html#36 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004q.html#63 creat
https://www.garlic.com/~lynn/2005f.html#14 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#15 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005j.html#41 TSO replacement?
https://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
https://www.garlic.com/~lynn/2005t.html#40 FULIST
https://www.garlic.com/~lynn/2005t.html#43 FULIST
https://www.garlic.com/~lynn/2005t.html#44 FULIST
https://www.garlic.com/~lynn/2005u.html#58 Command reference for VM/370 CMS Editor
https://www.garlic.com/~lynn/2006k.html#50 TSO and more was: PDP-1
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#43 MTS, Emacs, and... WYLBUR?
https://www.garlic.com/~lynn/2006n.html#45 sorting
https://www.garlic.com/~lynn/2006o.html#21 Source maintenance was Re: SEQUENCE NUMBERS
https://www.garlic.com/~lynn/2006s.html#3 THE on USS?
https://www.garlic.com/~lynn/2006s.html#15 THE on USS?
https://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?
https://www.garlic.com/~lynn/2007.html#24 How to write a full-screen Rexx debugger?
https://www.garlic.com/~lynn/2007g.html#4 ISPF Limitations (was: Need for small machines ... )
https://www.garlic.com/~lynn/2007g.html#5 Call for XEDIT freaks, submit ISPF requirements
https://www.garlic.com/~lynn/2007g.html#14 ISPF not productive
https://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?
https://www.garlic.com/~lynn/2007h.html#8 whiny question: Why won't z/OS support the HMC 3270 emulator

Disc Drives

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disc Drives
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2007 17:44:41 -0600
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
My machines stay on 24/7. Windows boxes have all automatic power downs disabled. Even screen savers are turned off, after I found that boxes would sometimes crash when trying to restore the screen. My hard drives have been running for years without a hitch.

for some topic drift .... increasing physical block size from 512bytes to 4096bytes ... improving capacity and error correction:

Hard drive changes: Long Block Data standard gets green light
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9018507

and some really ancient stuff ... old posts mentioning air bearing simulation application in support of designing the "new" floating/thin-film heads
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2002j.html#30 Weird
https://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
https://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
https://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
https://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
https://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
https://www.garlic.com/~lynn/2004b.html#15 harddisk in space
https://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#5 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#13 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#14 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006l.html#6 Google Architecture
https://www.garlic.com/~lynn/2006l.html#18 virtual memory
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#18 Why so little parallelism?
https://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007e.html#43 FBA rant
https://www.garlic.com/~lynn/2007e.html#44 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#46 The Perfect Computer - 36 bits?




previous, next, index - home