List of Archived Posts

2000 Newsgroup Postings (10/14 - 11/24)

Why trust root CAs ?

Why trust root CAs ?

Why trust root CAs ?

Why trust root CAs ?

Why trust root CAs ?

IBM Somers NY facility?

History of ASCII (was Re: Why Not! Why not???)

Why trust root CAs ?

Why trust root CAs ?

Optimal replacement Algorithm

Optimal replacement Algorithm

Amdahl Exits Mainframe Market

Amdahl Exits Mainframe Market

Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?

Why trust root CAs ?

Why trust root CAs ?

[OT] FS - IBM Future System

[OT] FS - IBM Future System

OT?

OT?

Competitors to SABRE?

OT?

Why trust root CAs ?

Why trust root CAs ?

Why trust root CAs ?

Why trust root CAs ?

OT?

OT?

OT?

OT?

OT?

OT?

Optimal replacement Algorithm

Optimal replacement Algorithm

Optimal replacement Algorithm

Why IBM use 31 bit addressing not 32 bit?

Optimal replacement Algorithm

OT?

Ethernet efficiency (was Re: Ms employees begging for food)

Ethernet efficiency (was Re: Ms employees begging for food)

Famous Machines and Software that didn't

Reason Japanese cars are assembled in the US (was Re: American bigotry)

IBM 3340 help

Reason Japanese cars are assembled in the US (was Re: American bigotry)

Al Gore and the Internet (Part 2 of 2)

Al Gore and the Internet (Part 2 of 2)

Al Gore and the Internet (Part 2 of 2)

Al Gore and the Internet (Part 2 of 2)

Famous Machines and Software that didn't

Al Gore and the Internet (Part 2 of 2)

Al Gore and the Internet (Part 2 of 2)

Al Gore and the Internet (Part 2 of 2)

TSS ancient history, was X86 ultimate CISC? designs)

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)

TSS ancient history, was X86 ultimate CISC? designs)

X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

TSS ancient history, was X86 ultimate CISC? designs)

Cryptogram Newsletter is off the wall?

Cryptogram Newsletter is off the wall?

360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

Building so big it generates own weather?

TSS ancient history, was X86 ultimate CISC? designs)

TSS ancient history, was X86 ultimate CISC? designs)

TSS ancient history, was X86 ultimate CISC? designs)

HASP vs. "Straight OS," not vs. ASP

SET; was Re: Why trust root CAs ?

Cryptogram Newsletter is off the wall?

Metric System (was: case sensitivity in file names)

Florida is in a 30 year flashback!

8086 Segmentation (was 360 Architecture, Multics, ...)

Reading wireless (vicinity) smart cards

TSS ancient history, was X86 ultimate CISC? designs)

Cryptogram Newsletter is off the wall?

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Sat, 14 Oct 2000 14:59:59 GMT

David Schwartz writes:

I think you'll find that if you do this, you recreate the PKI. First,
you'll want a central repository of whose key is whose. Second, you'll
want one place to go to revoke a key should it be compromised. And so
on.

you just don't need a certificate based PKI ... you go with an online,
real-time PKI.

The paradigm for the certificate model PKI was the offline email case
between parties that had no prior relationship and/or knowledge of
each other (i.e. connect to the network, download email, disconnect,
read email ... and perform various actions as specified by the email,
even tho you had no prior knowledge of &/or relationship with the
person sending the email).

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Sat, 14 Oct 2000 15:04:01 GMT

pbrdhd.nojunk writes:

On Sat, 14 Oct 2000 19:43:28 +1000, "Lyalc" <lyalc@ozemail.com.au>
wrote:
>If you replace Public Key with Password, this models works just as well, and
>works today, at zero incremental cost.

Scheme outlined has advantages over passwords which may justify the
incremental costs.  EG:
- a password is inherently less secure since it relies on keeping the
password secret, and yet password is known to all entities/devices for
which you use that password.  A public key can be put on a bill board
without lessening security.
- using a public key approach allows enables encryption of data unique
to the user, increasing security.
- the use of a device to handle the registration and authentication
simplifies the process from the point of view of the end user and
obviates the need to handle, remember and keep secure multiple
passwords.

replacing a password registerd in an account record with a public key,
the public key part of the protocol is the same whether the private
key is stored in a password protected software file, a hardware token
w/o any activiation, a hardware token with PIN activation, or a
hardware token with biometric activation, or a hardware token with
both PIN & biometric activation.

the public key part of the protocol is the same whether the consumer
registers the same public key with one location or the same public key
with 15 locations. In the case of multiple public key registration,
one might be the bank and another might be the consumer's ISP. Using a
common public key at both an ISP and the bank ... doesn't have the
downside of somebody at the ISP doing fraudulent transactions at the
bank.

deploying a common public key protocol would give the consumer a great
deal of freedom and choice as to the level of security and integrity
that they would like to use (software files, different tokens at
different integrity levels, activation, etc)

The PIN/biometric activation ... as opposed to authorization is an
issue. In the case of flowing an authorization PIN/password ... which
might get compromized, it is realitively easy to get a new
PIN/password. Biometric authorization in an open environment is much
harder to deal with (effectively biometric authorization is a complex
PIN/password that the person doesn't have to remember). In the case of
biometric authorization compromize, it is much harder to issue a new
body part. It is also harder to make sure that a unique body part is
used for each entity that the consumer wishes to authenticate with.

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Sat, 14 Oct 2000 19:32:00 GMT

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

"Verification" or authentication is not a boolean that you either have or
do not have.  Like all other security related things, authentication is
a continuous variable.  You can have a little or a lot, although it is
hard to have absolutely none and impossible to have absolute confidence.

and a wide variety of different business processes could select
different points on the landscape involving different levels of
integrity as well as behavior on the part of individuals

even within the same business process there could be very large
portion of the landscape coverage.

banks tend to have more confidence & experience with individuals that
they give $10,000 credit card limits to compared to individuals they
start out at $300 limits ... which can involve a broad range of
different factors and the weight/importance given those factors.

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Sun, 15 Oct 2000 00:15:32 GMT

David Schwartz writes:

There is no distinction in this case between a third and a second
party. In any arrangement, who does what can be changed. If banks want
to be CAs, they can be. It is, however, logical for banks to specialize
in banking. On the other hand, it's not necessarily logical for a CA to
specialize in certifying _financial_ transactions.

the bank doesn't really care if somebody certifies that you are you,
the bank really does care if the person they are dealing with is the
person that has rights to the account ... they surely can't use a 3rd
party to tell them which person has what rights to which account.

given that a bank can be sure that you are the person that has rights
to a particular account and that you own a private key (by
self-signing the corresponding public key) ... then the bank can
record the associated public key for that account.

the bank recording a public key may or may not involve the bank
returning a copy of a manufactured certificate. if there is a case
where they would return a copy of a manufactured certificate, the
original of that certificate is stored in the bank account record.

if the bank finds that the consumer is alwas returning a copy of the
manufactured certificate attached to a transaction sent to the bank,
then the bank can advise the consumer to do a little bit of knowledge
compression ... i.e. every field that exists in the copy of the
manufactured certificate that is also in the original of the
manufactured certificate stored at the bank ... can be compressed from
the copy of the manufactured certificate. Such compression can lead to
the efficiency of attaching zero byte certificates on every
transaction.

if the bank finds that the consumer is only attaching the copy of the
bank's manufactured certificate to transactions sent to the bank, the
bank can can save the consumer extra effort by precompressing the copy
of the manufactured certificate returned to the consumer (during
registration) ... i.e. by providing the consumer a zero byte
certificate that has been pre-compressed.

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Sun, 15 Oct 2000 16:24:56 GMT

"Lyalc" writes:

Yet private keys, that public keys depend upon are protected by the same
password you claim are insecure.  Weakest link rules apply here!

there is some difference between shared-secret pin/passwords ... and
locally owned pin/passwords.

Protecting my own property with pin/passwords .... for access to a
device I own myself .... is different than using shared-secret
pin/passwords that have to be registered with one or more entities
(and also different from dynamically generated per session encryption
keys).

The distinction between the different types of pin/passwords
(shared-secret versus private ownership) possibly is more clearly
illustrated in the case of biometric shared-secret ... i.e. the
electronic representation of the biometric body party is essentially a
much more complex version of a pin/password that doesn't have to be
remembered. In this kind of use of shared-secret pin/password in an
open network ... the compromize of a traditional pin/password allows
for changing the pin/password (although possibly expensive &
time-consuming operation).

The use of a shared-secret biometric body part in an open network
exhaserbates the problem of shared-secret pin/password compromize
because of the difficulty of changing body parts. The other
traditional guideline associated with shared-secret use is having a
unique value for each entity that you authenticate with ... implying
the use of a uniqe body part ... and hopefully you have fewer
authentication partners than you have body parts supported for
biometric authentication.

By comparison owning a personal hardware token that is biometrically
activated has different failure and exploit modes. There is not a
shared-secret biometric value that is being registered at multiple
locations and transmitted over networks on every authentication
operation. There is not cases of evesdropping a electronic biometric
code and being able to reproduce it for fraudulent transactions at
random places in the world.

In this scenerio, both the (public/private key) hardware token and the
biometric value has to be stolen. The consumer is able to obtain a
replacement hardware token and register its public key as needed ...
not encountering the difficulty associated with having body parts
replaced (associated with compromize of shared-secret biometric
paradigms).

random refs:

http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3
http://www.garlic.com/~lynn/aadsmore.htm#biosigs
http://www.garlic.com/~lynn/aadsmore.htm#biosigs2
http://www.garlic.com/~lynn/99.html#157
http://www.garlic.com/~lynn/99.html#160
http://www.garlic.com/~lynn/99.html#165
http://www.garlic.com/~lynn/99.html#166
http://www.garlic.com/~lynn/99.html#167
http://www.garlic.com/~lynn/2000.html#57

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

IBM Somers NY facility?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Somers NY facility?
Newsgroups: comp.lang.asm370
Date: Tue, 17 Oct 2000 15:26:23 GMT

lwinson@bbs.cpcn.com (lwin) writes:

Would anyone know what kinds of offices IBM has at its Somers NY
facility?  Anything open to the public, such as demonstration centers
or any kind of equipment showroom?
(I know the archives are there.)

coming up the turnpike from the south ... it looks like a "pyramid
power" building ... lobbies of the different sections have large glass
pyramids rising above the rest of the structure. in theory one could
stand in one of the lobbies directly under the peak of the pyramid and
collect energies.

last time we were there it was hdqtrs for different "groups"
(i.e. various divisions had their hdqtrs at various locations around
the world, divisions were collected into groups ... and somers had
executives & staffs at the group level).

the other interesting building was "purchase" ... which was in the
process of being built for a food company. lots of marble and big
spaces.

for whatever reason it was picked up on a really good deal. however, i
think that two years ago mastercard picked it up on another really
good deal for their hdqtrs (they consolidated a number of different
locations on manhatten).

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

History of ASCII (was Re: Why Not! Why not???)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of ASCII (was Re: Why Not! Why not???)
Newsgroups: comp.lang.java.programmer,alt.folklore.computers
Date: Wed, 18 Oct 2000 20:58:21 GMT

Tom Almy writes:

Obviously, my memory failed here! I did start out with IBM equipment,
and you are right in that the "correspondence" keyboard was on the IBM 2741
terminal I used, which differed from the keyboards on the keypunches.
And even there there were different layouts.

2741 came standard and correspondance. CP/67 determined which
translate table to use by sending the login message using both
standard & non-standard bit pattern.

The user was then expected to type login followed by their userid. If
the first character translated to "l" (aka login) using the standard
translate table ... it was assumed to be a standard 2741. Otherwise it
would switch & try the correspondance translate table ... looking for
a "l" as the first character.

from some old translate table index:

00           2741
04           correspondance 2741
08           apl 2741
0c           correspondance apl
10           tty
-
18           apl tty

... i.e. 08 bit was used both as part of the translate table indexing
but also as flag indicating APL translate command had been issued.

when i originally added tty/ascii support to cp/67 in 68 ... i had to play
around with some of the non-standard ascii key assignments.

I also tried to extend the dynamic terminal type recognition so that
TTY, 2471, and 1050s could dial into the same rotory bank. The ibm
2702 line controller had SAD command that controlled which line scanner
was associate with which address.

On initial connect, I do something like specify the SAD for the tty
line scanner and then send a who are you. If that timed out, i would
specify the SAD for the 2741 line scanner and try some things.

It actually worked ... except eventually i talked to a ibm hardware
engineers who said that it was out of spec. While ibm supported
changing the line scanner with the SAD command, they took a short cut
in the implementation and hard-wired the oscillator to each line
... i.e.  "tty" lines would have an oscillator hard wired for 110 baud
and "2741" lines would have an oscillator hard wired for 134.? baud.

Learning that eventually led to a 4-person project that built a
plug-compatible controller out of Interdata3 (and credited with
originating the ibm plug-compatible control unit business). One of the
things that was supported was (relatively) high frequency strobe of
incoming initial bits to dynamically determine baud rate.

random refs:

http://www.garlic.com/~lynn/93.html#2
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/96.html#9
http://www.garlic.com/~lynn/96.html#12
http://www.garlic.com/~lynn/96.html#30
http://www.garlic.com/~lynn/96.html#37
http://www.garlic.com/~lynn/96.html#39
http://www.garlic.com/~lynn/99.html#44
http://www.garlic.com/~lynn/99.html#76

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Wed, 18 Oct 2000 21:02:39 GMT

pbrdhd.nojunk writes:

Agreed, but I wasn't proposing that biometric be used except on the
local device which holds the private key.  Ideally this would be a
tamper proof print recognition smartcard, so people would have the
convenience of just thumbing their card while it is slotted to
authorise/authenticate a transaction, but the print recognition data
would be not be held or used anywhere off the card. This way the
critical authentication info in the wider system is still the key pair
for which the private key is held on the card, not the
bio-recognition data which is used purely locally to authorise the use
of the private key.

if we aren't careful ... we'll find ourselves in violent agreement.

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Wed, 18 Oct 2000 23:49:41 GMT

Greggy writes:

If you were a bank and you had these choices before you and your
marketing people were telling you that you can either:

A) use this totally insecure CA strategy and provide your customer base
with a very simple to use web site that would save you money in teller
payrolls

or

B) use a real strategy for security that makes your customers work
harder, which in turn would drive your customers away from your new web
sites (and you lose the payroll savings as well)

which would you choose?

there have been other situations making such claim regarding
things like CAs & certificates in financial infrastructures.

the frequent fallicy is ignoring the fact that customer support is
required and that requires things like answering questions about
pieces and components (i.e. a 1-800 number in the case something
doesn't work ... who does the customer call).

in order for the call center to effectively answer calls ... they need
access to the related components ... which leads a financial
institution to registering the components in databases accessable by
the call centers.

the per screen lay-out costs at the call center and the registration
process in support of the call center frequently dominate all the
costs associated with any such activity (regardless of the
implementation).

of course the above only applies to real-live roll-outs and can be
bypassed/ignored in the case of toy pilots, in which case other
trade-off decisions can be made regarding the degree of investment in
toy pilots (i.e. like punting on the issue of providing customer
support).

One of the issues for toy pilots can be assumption that the early
adapter participation in toy pilots will self-select ... i.e.
everything goes right and the individual participates or it doesn't go
right and they don't participate.

getting out a technology "with-it" press release on a toy pilot, it is
possible to cut all sort of corners, possibly leaving worrying about
the real implementation later after testing the water.

Furthermore, CA/certificates as being easy for customers and
non-CA/certificates as being hard for customers is not a proven
generalization (improved integrity doesn't have to be unnecessarily
intrusive).

Skirting the requirement of expense for full customer support in
association with toy pilots is probably a much better understood
generalization.

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

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Thu, 19 Oct 2000 15:25:32 GMT

Alexis Cousein writes:

agelman1@san.rr.com wrote:

On Sat, 07 Oct 2000 19:13:31 GMT, "Kevin Lai" <kev1997@ms15.hinet.net>
>What is the "Optimal Replacement Algorithm", in a few words?
>Thanks.

Just what it says -- optimal. It has one "slight" drawback in that it isn't
causal (i.e. requires you to know not only information about accesses in the
past, but also accesses that are going to happen in the future).

I think about the time belady published paper on optimal at IBM YKT
... IBM CSC was doing simulation work LRU, random, fifo, 1-4 bit
clock, etc. I believe there was also a ACM paper from project mac on
1-4 bit reference and a ACM paper out of Brown on a timer counter in
place of bits (again all about the same period).

The IBM CSC simulation work had found a variaion on 2bit clock that
outperformed true LRU (in simulations across wide variety of live trace
data).

Basically the characteristic is that true LRU nominal outperforms FIFO
... except in situations where LRU degrades to FIFO ... and for those
situations RANDOM tends to be better ... the issue then becomes
recognizing when to switch back and forth betweeen LRU and RANDOM.

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

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Thu, 19 Oct 2000 20:52:07 GMT

toor@y1.jdyson.net (John S. Dyson) writes:

Take a look at my FreeBSD VM page replacement algorithm...  It works
surpisingly well, and converges very rapidly to a reasonable working
set under load.  It is deceptively simple, and effectively adapts to
the all of the usage and transfer rates.  It isn't any of the degenerate
clock-type, LRU, random type algorithms, but is a learning hybrid.

part of the LRU & LRU approximations is the assumption that passed
behavior predict future behavior ... sometimes that is true and
sometimes it isn't true (as well as working set members & working set
size). the adaptive transition (work circa '70-'71) between LRU and
non-LRU attempted to correspond with different execution
characteristics & behavior.

other adaptive characteristics were relative miss latency, relatively
miss bandwidth and relative cache/storage size.

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

Amdahl Exits Mainframe Market

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amdahl Exits Mainframe Market
Newsgroups: bit.listserv.ibm-main
Date: Fri, 20 Oct 2000 22:46:45 GMT

scotth@aspg.com (Scott Harder) writes:

The "dumbing down" has been going on a long time in data centers around the
country for a number of years.  I saw system automation take what used to be
very smart Operations people and turn them into nothing more than babbling
idiots - only able to see something that looked abnormal and place a phone
call to Technical Support.  Actually, Ops. Mgmt where I worked loved it
because they no longer had to take any blame.

It took a while to fully dumb down all areas of Operations (I know what
you're thinking and you should be ashamed!) and now the sights are set on
the majority of Technical Services, leaving one or two gurus in the shop.

It was bound to happen, but me thinks the pains will be a little more
intense in getting Technical Services "dumbed down".  Then who will the
finger be pointed at when something goes wrong?????

My $0.02,

I know of two large gov. labs that had large, heavily invested MVS
shops ... and both migrated to Unix because they were unable to obtain
MVS technical expertise. One of the labs. retired the MVS complex on
approx. the same day as their last senior MVS technical support
retired after being nearly 30 years in the position. The other
location had several MVS technical openings advertised for over 12
months, existing MVS technical personel were being lured away to
better paying commercial jobs, the number of MVS openings were growing
and they had been unable to backfill any of them for over a year.

From their standpoint, dumbing down MVS support would be a response
to being unable to fill the positions.

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

Amdahl Exits Mainframe Market

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Amdahl Exits Mainframe Market
Newsgroups: bit.listserv.ibm-main
Date: Fri, 20 Oct 2000 22:53:29 GMT

on the otherhand ... part of a large financial infrastructure credited 100%
up time (24/7) solid for over six years (now outages) to

1) ims hotstandby
2) automated operator

as various hardware & software failures were eliminated, operator mistakes
became one of the largest remaining failure causes.

http://www.garlic.com/~lynn/99.html#71

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

Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?
Newsgroups: alt.folklore.computers
Date: Sat, 21 Oct 2000 15:30:28 GMT

erg@panix.com (Edward Green) writes:

ObComputerFolklore:  Besides design, and I imagine the SR-71 _was_
designed with the aid of supercomputers at _least_ as powerful as
a Pentium-II desktop, we may discriminate based on onboard computers,
and to what extent the pilot is a pilot vs. a spectator.  I think
in the case of the X-15 whose irrelevantly stubby wings ultimately
prompted your comment, we had a true "piloted rocket" which required
the full heroic skill of Chuck Yeager and his pals to operate.

i remember boyd saying that they used supercomputer time for designing
the F16 ... using "boyd's law" ... basically stuff about performance
envelopes and analysis of trade-offs early '70s (but that was even
before cray-1 which wasn't shipped until '76)

http://www.arnold.af.mil/aedc/highmach/stories/f16.htm
http://web.archive.org/web/20010222212740/http://www.arnold.af.mil/aedc/highmach/stories/f16.htm
http://www.defense-and-society.org/FCS_Folder/boyd_thesis.htm
http://web.archive.org/web/20010722090426/http://www.defense-and-society.org/FCS_Folder/boyd_thesis.htm
http://www.garlic.com/~lynn/99.html#120

SR-71 was early 60s ... so even 6600 would not have been available

http://209.1.224.11/CapeCanaveral/Lab/3993/SR71.html
http://web.archive.org/web/20010222210304/http://209.1.224.11/CapeCanaveral/Lab/3993/SR71.html
http://www.airspacemag.com/asm/mag/supp/fm99/oxcart.html
http://web.archive.org/web/20010204132600/http://www.airspacemag.com/asm/mag/supp/fm99/oxcart.html

6600 avail. 9/64

http://www.isham-research.freeserve.co.uk/chrono.txt
http://www.cray.com/company/history.html
http://web.archive.org/web/20010203153300/http://www.cray.com/company/history.html
http://ei.cs.vt.edu/~history/Parallel.html

stretch & 7090 would have been available in the sr-71 timeframe and
there were little or no plane design related applications available at
that time.

in the f-16 timeframe had 7600,  91/95/195, misc. others

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Sun, 22 Oct 2000 21:53:21 GMT

"David Thompson" writes:

Yes, if the merchant is abusive, or hacked, you have a problem
in any account-based scheme -- only anonymous "cash" solves
that.  Or throwaway accounts kept confidential by the issuer;
or whose issuance is itself anonymous (but at present only
banks can do this and AFAICT they aren't willing to do so).
Or non-technical means like data-subject protection laws
that are enacted and enforced, but that's getting offtopic.

or authenticated account transactions as in X9.59 (financial industry
draft standard for all retail electronic account-based transactions).

x9 (financial industry standards org) overview at: http://www.x9.org

the nominal requirements given the x9a10 working group for x9.59 work
item was to preserve the integrity of the financial infrastructure
for all electronic retail payment (account-based) transactions with
just a digital signature.

in effect only authenticated transactions are supported for these
account (numbers) ... i.e. non-authenticated transactions against
x9.59 account numbers may not be authorized (note today a financial
institution may map multiple different account numbers with different
characteristics to the same account ... so there is nothing precluding
having both authenticated account number and a non-authenticated
account number mapping to the same account ... and the authorization
risk rules can be different based on the transaction type).

misc. details on x9.59 at http://www.garlic.com/~lynn/

there is a mapping of x9.59 to iso8583 (i.e. payment cards, debit,
credit, etc)

http://www.garlic.com/~lynn/8583flow.htm

misc. other discussion (authenticated transactions, privacy,
name/address issues, etc)

http://www.garlic.com/~lynn/99.html#217
http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/aadsm3.htm#cstech13
http://www.garlic.com/~lynn/ansiepay.htm#privacy
http://www.garlic.com/~lynn/aadsmore.htm#x959demo
http://www.garlic.com/~lynn/aepay3.htm#sslset2
http://www.garlic.com/~lynn/aepay3.htm#x959risk2

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Sun, 22 Oct 2000 22:20:54 GMT

Anne & Lynn Wheeler writes:

there is a mapping of x9.59 to iso8583 (i.e. payment cards, debit,
credit, etc)

one of the issues in mapping digital signatures to the existing
payment infrastructure and providing end-to-end authentication ... was
the typical 8583 message was 60-100 bytes. It was possible to map the
additional x9.59 fields and a ec/dss into something like an additional
80 bytes or so (nearly doubling message size for authentication).

A certificate-based infrastructure represented two approaches ...

1) use certificates in an internet-only mode and truncate them at
boundary between the internet and the financial infrastructure. The
downside was giving up on basic security tenets like end-to-end
integrity and end-to-end authentication.

2) carry the certificate ... but compress it into a manageable mode.

Now, some things cropped up:

Justification for the financial institution registering the public key
were a) provide sufficient information for customer call center to
handle trouble calls related to digital signature transactions and b)
support relying-party-only certificates. relying-party-only
certificates basically carried only an account number ... and designed
by financial institutions to address liability and privacy issues.

With transactions carrying only a an appended relying-party-only
certificate ... the account record has to be read ... containing the
original of the certificate.

Therefor flowing any such certificate at all through the
infrastructure can be viewed in one of two ways:

1) it is possible to compress out of a transaction appended
certificate every field that the recepient is known to already
have. Since the recepient has the original of the appended
certificate, then every field in a transaction appended certificate
can be removed ... resulting in a zero-byte appended certificate

2) given the the consumer has a copy of the certificate, while the
recepient (financial institution) has the original of the certificate
that will be read when the transaction is executed, it is redundant
and superfluous to bother sending back to the recepient a copy of
something the recepient already has (i.e. the original registered
public key along with all its binding).

So the x9.59 mapping to 8583 can viewed as either a) carrying a
zero-byte appended certificate ... or b) not bothering to
superfluously transmit to the financial institution a copy of some
information (i.e. a public key and the public key bindings, represeted
by a certificate) appended to every transaction when the financial
institution has the original of that same information. In either case
it minimizes the transaction payload bloat incurred by adding
transaction authentication.

The X9.59 mapping to 8583 with included digital signature can provide
end-to-end transaction authentication ... i.e. financial transaction
instruction from the consumer to the consumer's financial institution
... with the institution responsible for authorizing and executing the
financial transaction instruction is actually also authenticating the
same instruction.

In prior posts, it was also pointed out that it is redundant and
superfluous (as well as raising privacy issues) if parties not
responsible for executing the transaction are performing extraneous
authentication operations on the transaction.

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

[OT] FS - IBM Future System

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] FS - IBM Future System
Newsgroups: bit.listserv.ibm-main
Date: Mon, 23 Oct 2000 04:27:54 GMT

wmhblair@INTERTEX.NET (William H. Blair) writes:

Many ideas that were circulating around this time are also discussed in
the archives of my former neighbors, Anne & Lynn Wheeler: refer to their
web site at http://www.garlic.com/~lynn/

some of the postings i've made on the subject:

http://www.garlic.com/~lynn/96.html#24
http://www.garlic.com/~lynn/99.html#100
http://www.garlic.com/~lynn/99.html#237
http://www.garlic.com/~lynn/2000.html#3

a couple  URLs found from alta vista

http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Index.html
http://www.cs.clemson.edu/~mark/acs_people.html

from

http://www.ecole.org/Report_IBM.htm
http://web.archive.org/web/20010107165600/http://www.ecole.org/Report_IBM.htm
<<NOTE: above now 404, a current pointer:
http://www.ecole.org/Crisis_and_change_1995_1.htm

IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead
that the competition would never be able to keep up, and to have such
a high level of integration that it would be impossible for
competitors to follow a compatible niche strategy. However, the
project failed because the objectives were too ambitious for the
available technology.  Many of the ideas that were developed were
nevertheless adapted for later generations. Once IBM had acknowledged
this failure, it launched its 'box strategy', which called for
competitiveness with all the different types of compatible
sub-systems. But this proved to be difficult because of IBM's cost
structure and its R&D spending, and the strategy only resulted in a
partial narrowing of the price gap between IBM and its rivals.

... &

This first quiet warning was taken seriously: 2,500 people were
mobilised for the FS project. Those in charge had the right to choose
people from any IBM units. I was working in Paris when I was picked
out of the blue to be sent to New York. Proof of the faith people had
in IBM is that I never heard of anyone refusing to move, nor
regretting it. However, other quiet warnings were taken less
seriously.

===============================================================

as in prior postings ... my view at the time was "inmates in charge of
the asylum", didn't exactly make me liked in that group ... see ref in
previous postings (above) to central sq. cult film.

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

[OT] FS - IBM Future System

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [OT] FS - IBM Future System
Newsgroups: bit.listserv.ibm-main
Date: Mon, 23 Oct 2000 04:38:00 GMT

oh, and on the subject of "compatible" ... recent posting touching on the subject
of plug-compatible ...

http://www.garlic.com/~lynn/2000f.html#6

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 23 Oct 2000 16:57:37 GMT

Steve Samson writes:

FS was never promised. It was a code name for a new system that started
sometime in the late '60s and was shelved in the early '70s. The big
innovations were to be object orientation and a one-level store. That
is, the "file system" was an extension of memory addressing.
...
The big barriers still uncrossed are the one-level store and FBA DASD. I
think they've been substantially mooted by other developments.

Most of the stuff was around at the time of FS and "collected" as part
of the project.

One-level store ... as tried by tss/360 a couple years prior to FS
didn't work ... for one thing, the semantics between file access and
virtual memory management were too primitive from at least a
performance standpoint (i.e. LRU replacement algorithms didn't work
well on virtual memory spaces being accessed sequentially).

The big issue for any of the OSs/VSs supporting FBA was CKD
multi-track search for vtoc, pds, etc. CKD multi-track search was a
technology trade-off from the mid-60s based on relative memory sizes
and i/o bandwidth (trading off decreased memory utilization for
increase i/o utilization). By the late-70s, the trade-off had flipped
(shifted from being memory constrained to I/O constrained) ... and CKD
searches were limiting system thruput. I got something like a quote
from STL for $26m pricetag to ship vtoc & PDS support for non-CKD
operation (even showing significant performance improvement).

random refs:

http://www.garlic.com/~lynn/97.html#29
http://www.garlic.com/~lynn/99.html#237
http://www.garlic.com/~lynn/2000b.html#54
http://www.garlic.com/~lynn/2000c.html#75
http://www.garlic.com/~lynn/2000f.html#9
http://www.garlic.com/~lynn/2000f.html#10

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 23 Oct 2000 17:03:08 GMT

Anne & Lynn Wheeler writes:

The big issue for any of the OSs/VSs supporting FBA was CKD
multi-track search for vtoc, pds, etc. CKD multi-track search was a

aka CKD multi-track search was inhibitor in supporting FBA ... however
replacing CKD multi-track search with different strategy saw
significant performance thruput regardless of whether device was CKD
or FBA.

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

Competitors to SABRE?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Competitors to SABRE?
Newsgroups: alt.folklore.computers
Date: Mon, 23 Oct 2000 23:02:54 GMT

ehrice@his.com (Edward Rice) writes:

Sounds like IBM-promoted hype to me.  A little 7-man shop I worked for
(after the initial development was done) developed a system capable of
something like 300,000 transactions per hour on a dual-processor Honeywell
box (i.e., not an especially large or fast system).  NASDAQ ran on a pair
of 1108's through the 1970's.  IBM would like to think that it was the
biggest and the best in all ways, but in fact SABRE was a /very/
special-purpose system which is pretty hard to even call an "operating
system."  You can define, in an environment like that, what you'll call a
"transaction" -- was SABRE's definition "buy a ticket" which is what the
customer would see as an atomic piece of work, or was it "query db for
flight number" plus forty other queries and updates, linked, which would
tend to escalate the transaction count by many-fold from what the user
might see?  You can make production statistics lie just lie you can make
any other kind of statistics lie.

in the early '90s i got to look at "routes" which represented 25% of
the transactions on a large airline res system (typically 3-4 "linked"
transactions). They gave me a list of 10 impossible things that they
had been grappling with (many in large part because of problems with
the limited dataprocessing facilities provided by the system ... in
effect, TPF was slightly more than some of the dedicated purpose
real-time systems ... as opposed to a real operating system).

as an aside, 20-30% of the transactions involved directly driving the
various ticket printing and other devices around the world ... however
avg. peak load (for the whole system) was still several thousand per
second (not per minute or per hour ... but per second).

I redid routes that addressed all ten impossible things and had
something like 10times the thruput; it wasn't TPF-based (in large part
because the application was implemented in a totally different way
... and not subject to various restrictions imposed by a TPF-based
implementation).

TPF is also used in some transaction switching systems in the
financial industry (imagine a large router in tcpip/internet genre)

random refs:

http://www.garlic.com/~lynn/99.html#24
http://www.garlic.com/~lynn/99.html#100
http://www.garlic.com/~lynn/99.html#103
http://www.garlic.com/~lynn/99.html#136a
http://www.garlic.com/~lynn/99.html#152
http://www.garlic.com/~lynn/99.html#153
http://www.garlic.com/~lynn/2000.html#31
http://www.garlic.com/~lynn/2000.html#61

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 23 Oct 2000 23:23:11 GMT

Steve Samson writes:

I don't disagree with your first statement. What I said was that the
marketoons (DPD at the time) thought that they couldn't sell FS, and
since all the top IBM management came from the marketing side, the
technicians could not make their case.

(at least a) nail in the coffin was the houston science center showing
a FS machine implemented on fastest ibm (supercomputer) technology
(370/195+) at the time would be running applications at approximate
thruput of 370/145.

that is aside from various issues of actually getting the vast array
of new technologies all developed, tested, integrated, and into the
market in any reasonable time-frame.

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Tue, 24 Oct 2000 00:03:09 GMT

"Tor Rustad" writes:

I'm reading your posts with interest, and will look into some of your links
on this matter. I must admit that I have not paid attention to X9.59. In
SET, the ISO8583 mapping is implemented already, why do we need another way
to do this? To open up for on-line debet card transactions?

As long as the card companies allow no security via credit cards, and the
banks earn more mony (in some countries) on credit card transactions, the
business case for implementing X9.59 doesn't look good. Also, _if_ X9.59
mandates new messages at the ASN.1 level, this will be expensive to
implement. Futhermore, some of us are starting to get really fed up with all
these PKI standards...

there is existing fraud ... even w/o the internet.

SET didn't provide end-to-end authentication. It truncated
authentication at the SET payment gateway and then generated an
acquiring financial infrastructure transaction with a flag indicating
authentication ... which eventually got to the customer's issueing
financial institution.

Two years ago, somebody from VISA gave a presentation at an ISO
meeting regarding the number of (SET) transactions coming into
consumer issuing financial institutions with the SET authenticated
flag turned on ... and they could show that there was no SET
technology involved in the transaction (issue crops up in security
infrastructures when there isn't end-to-end authentication and
end-to-end integrity).

The X9.59 mapping to ISO8583 is done in much the same way that the SET
mapping was done ... find a place in the existing ISO8583 message
definition to stash the information ... so that ISO8583 doesn't have
to be changed (although the 8583 work group now has a new field being
defined that would specifically support this function).

If you note that the X9.59 standard doesn't really define messages
... it defines a set of fields formated for digital signature signing
and authentication. It specifically doesn't say how the fields are
transmitted on an end-to-end basis ... it just defines how the fields
have to be formated when they are signed and how the fields have to be
formated when the signature is verified. In this sense, it took a
similar approach to that of FSTC (
http://www.fstc.org &
http://www.echeck.org ) for digitally
signed electronic checks (the transmitted messages carrying the fields
may bear absolutely no resemblance to the format of the fields for
signing and authentication). And in fact, with minor changes, the
X9.59 definition (if translated to XML/FSML encoding) is useable for
echeck (i.e. the charter given the X9A10 work group was to preserve
the integrity of the financial infrastructure for all electronic
retail payment (account-based) transactions with a digital
signature).

The industry has regular message and software upgrades ... some of
them dictated by regulations ... and more than a quite a few changes
that are orders of magnitude larger change compared to what is needed
for x9.59. The resources needed to effect the X9.59 changes, if
scheduled as part of standard industry change process ... might not
even show up as a real line item (lost in the noise of business as
usual).

Standard business case applies to X9.59 ... benefits outweight the
costs. Done as part of normal business, the technology, development,
and deployment costs of X9.59 can be managed into the noise range.  As
cited in previous postings ... those costs however are totally dwarfed
by costs of deploying real live customer call center support for new
kinds of technology transactions.

One of the issues with X9.59 is that it has been defined as part of
the industry financial standards process ... for implementation as
part of standard production operation. In order to achieve end-to-end
integrity, it doesn't define toy pilots that might be do'able for $50k
where the authentication and integrity may be stripped off at the
internet boundary (as an aside, development, test, deployment and
training for one new screen in a customer call center can easily be
more than the cost of a toy pilot ... the real costs for new kinds of
technology is how to provide customer support ... if done correctly,
the technology issues can be managed into the noise range).

So what are compelling business issues for end-to-end authentication
and integrity ... along with fraud & risk reduction?

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Tue, 24 Oct 2000 00:14:51 GMT

vjs@calcite.rhyolite.com (Vernon Schryver) writes:

What's the big deal about +/- 60-180 bytes on the wire?
Yes, I realize that multiplying umptyzillion transactions per day by 60
bytes amounts to a lot of bits per second, but modern network performance
is determined to the first order by the number of packets, not the number
of bytes or the sizes of packets.

It costs the same (for all reasonable meanings of "cost") to send
a packet containing 80, 160, or 180 bytes on a modern network, with
the possible but quite implausible exceptions of some radio-telephone
and low speed modem links.

Part of the reason for that is network traffic is so extremely bursty
("self-similar") that you must over-provision, or your customers get
unhappy because sometimes their dirty HTTP pictures take longer to appear.

the issue is relying on existing infrastructure ... built around the
80-160 byte messages. FOr instance, I've seen reports that SET
certificates ranged in size from 2k bytes to a high of 12kbytes.

Part of the X9.59 work was that it could be mapped to a brand new
network where all the bandwidth rules have totally changed ... and it
wasn't necessary to worry about existing practical concerns. So at at
the 100,000 foot level ... does a definition also carry as a
prerequisite that brand-new financial infrastructure be built in order
to support its deployment.

However, part of the X9.59 work was also to see how it could be mapped
to existing ISO8583 financial networks where there are real bandwidth
rules and transactions size issues ... and still provide end-to-end
integrity and end-to-end authentication.

Part of the charter given the X9A10 work group was to preserve the
integrity of the financial infrastructure for all electronic retail
payments (account-based) with a digital signature. "All" would
include all the existing financial infrastructures as well as the new
ones that haven't been built and deployed yet (i.e. the charter wasn't
to define an internet only solution or a new network only solution, it
was a solution for all electronic retail account-based payments).

It is believed that the same X9.59 definition can be made to work in
both kinds of environments (the existing financial infrastructures as
well as the new infrastructures that haven't been built yet).

there is a line someplace about, in theory there is no difference
between theory and practice, but in practice there is.

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Tue, 24 Oct 2000 00:35:23 GMT

Anne & Lynn Wheeler writes:

there is a line someplace about, in theory there is no difference
between theory and practice, but in practice there is.

and besides ... it is redundant and superfluous to transmit a copy of
something (and appended transaction certificate) possibly thousands of
times a day ... to somebody that has the original. Even HTTP browswers
know about caching and trying to avoid redundant and superfluous
transmission.

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

Why trust root CAs ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why trust root CAs ?
Newsgroups: sci.crypt
Date: Tue, 24 Oct 2000 00:39:57 GMT

Anne & Lynn Wheeler writes:

authentication). And in fact, with minor changes, the X9.59 definition
(if translated to XML/FSML encoding) is useable for echeck (i.e. the
charter given the X9A10 work group was to preserve the integrity of
the financial infrastructure for all electronic retail payment
(account-based) transactions with a digital signature).

one of the FSML issues was the lack of deterministic encoding rules in
standard markup language definitions. In the possibility that the
fields in a signed object ... are not transmitted in the signed object
bit representation ... the recepient has to be able to exactly
recreate the original object bit representation (in order to verify
the signature) from the transmitted fields (regardless of how they are
transmitted). The authenticating entity needed to follow the same
deterministic (markup language) encoding rules in recreating the
signed object that were followed by the signer when the original
orject was created (for signing).

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 24 Oct 2000 00:48:03 GMT

jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:

Houston Science Center? I never knew there was such a thing...possibly
because it may well have predated my entry into the mainframe world in 1981.
Was it down at JSC (MSC)?

i believe houston and philidelphia science centers were consolidated
about the same time ... mid to late '70s (Philidelphia was where
falkoff and iverson had done APL)? Bill Timlake came up from the
Houston Science Center sometime in the 74/75 timeframe to head up the
Cambridge Science Center.

searching alta vista for ibm houston science center ... came up with
the former FSD houston location (one of the few things that didn't go
when IBM sold the federal system division).

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 24 Oct 2000 00:58:14 GMT

Steve Samson writes:

Well, yes but ... it did not all have to come out at once, if a suitable
migration scenario had been devised. That's one area where the techies
fell down. The Houston benchmark could have proven anything since the
3-layer FS design had tremendous optimization opportunities at each
level. I find it hard to believe that the model recognized what was in
the pipeline, rather than just was available off the shelf. Depends what
they wanted to prove.

one might be able to make the claim that they did exactly that and it
is now called AS/400 (and there was 5-layer hardware FS).

FS seemed to garner every new R&D idea that had been thot of
... whether it was practical or not (some line about in theory there
is no difference between theory and practice ... but in practice there
is). Technies not being able to sort between practical and not
practical were going to take quite awhile to getting around to
devising any sort of migration plan.

I think that houston prooved that the very next product out the door
from IBM was going to be a 370-based product and not an FS-based
product.

in any case, the focused effort that was being done instead of continueing
to produce products for the existing market place was suspended(?).

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 24 Oct 2000 01:13:25 GMT

Steve Samson writes:

p.s. BTW, who is actually writing these "Anne & Lynn" messages? Is it
like piano four hands?

my wife and I share a PC ... but as far as i know she has never
bothered to post to any scientific, engineering, computer and/or ibm
newsgroup.

as to FS ... I'm biased because I believe what I was shipping at the
time was superior to what was defined as research in the resource
management section.

my wife is biased the other way ... she reported to the guy that
headed up inter-system coupling area (FS was divided into something
like 13-14 sections/areas ... resource management was one of the area
sections & inter-system coupling was another area/section) for FS
(before she went to POK to be responsible for loosely-couple
architecture). she does admit now that a lot of it was extremely blue
sky (but it was fun even if not practical).

random refs:

http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/95.html#13

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 24 Oct 2000 01:25:19 GMT

Anne & Lynn Wheeler writes:

one might be able to make the claim that they did exactly that and it
is now called AS/400 (and there was 5-layer hardware FS).

and parallel sysplex staged delivery of work my wife did in the FS
inter-system coupling area before going to POK to be responsible for
loosely-coupled architecture.

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 24 Oct 2000 14:11:08 GMT

Anne & Lynn Wheeler writes:

my wife is biased the other way ... she reported to the guy that
headed up inter-system coupling area (FS was divided into something
like 13-14 sections/areas ... resource management was one of the area

Les Comeau was with IBM at MIT doing CTSS days and early cambridge
scientific center ... and headed up the CP group that implemented
CP/40 and early CP/67. see melinda's paper at

http://www.princeton.edu/~melinda/

In the late '60s Les transferred to Wash DC. During FS he was head of
the inter-system coupling section/area in FS. My wife worked for
him. After FS was shutdown, my wife spent some time working on
JES2/JES3 in g'burg and then went to POK to be responsible for
loosely-coupled architecture. She did peer-coupled shared data
architecture and fought for things like making trouter/3088 more than
just CTCA.

About the time she was in POK, I was on the west coast and doing some
things for HONE ... both SMP kernel support and helping with
loosely-coupled support (at the time, the resulting implementation was
considered the largest single system image complex in existance).

http://www.garlic.com/~lynn/2000c.html#30

I also got to do a from scratch implementation for HYPERchannel that
looked more like what she was pushing for trouter/3088 and had some of
the characteristics from fs inter-system coupling. It was deployed by
the IMS organization in STL and Boulder.

http://www.garlic.com/~lynn/2000b.html#29
http://www.garlic.com/~lynn/2000b.html#38

I then did the rfc 1044 support in ibm's tcp/ip ... with thruput about
50* the base implementation (again, much more characteristic of fs
inter-system coupling)

http://www.garlic.com/~lynn/93.html#28
http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/2000.html#90
http://www.garlic.com/~lynn/internet.htm#0

Her per-coupled shared data didn't really make it into the (mainframe) market
until ims hot-standby ... and now parallel sysplex.

http://www.garlic.com/~lynn/99.html#71

Later when we running the skunk works that turned out HA/CMP, a lot of
the implementation was subcontracted to a company in Cambridge called
CLaM. Les had moved back to Boston and formed a company CLaM ...
initials stood for Comeau, Linscott and Miller. misc. refs:

http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/2000d.html#2

so there could be a claim made that a lot of the work on FS
inter-system coupling did eventually migrate into products
(independent of other parts of FS showing up in as/400).

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 24 Oct 2000 14:40:28 GMT

Also, somewhat in conjunction with HA/CMP ... we worked on getting
some various forms of high-speed interconnect for the 6000 (before
starting on FCS support). We used the term HSDT (high-speed data
transport) for this part of the skunk-works (lots of stuff from fs
inter-system coupling).

The 6000 group had done effectively their own version of escon
... called SLA (serial link adapter) ... it was about 10% faster than
escon and used components that were something like 1/10th the cost of
the escon components.

However, there was nobody else in the world that supported SLA ... so
at best, one 6000 box could talk to another 6000 box.

To make it more interoperable ... we con'ed the company that produced
HYPERChannel and very high-end tcp/ip routers to support a SLA card
in their product line (they had a full set of directly attached boxes
supporting a wide range of vendor supercomputers and mainframes, in
addition to high-end, high-performance routers). With their support of
SLA ... it gave the 6000 high-truput attachment directly into every
kind of computer supported by their product line.

another random hsdt ref (rios in the following ref is rs/6000)

http://www.garlic.com/~lynn/99.html#67

random other hsdt refs:

http://www.garlic.com/~lynn/94.html#22
http://www.garlic.com/~lynn/94.html#33b

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

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Wed, 25 Oct 2000 14:55:19 GMT

toor@y1.jdyson.net (John S. Dyson) writes:

You'll find that FreeBSD performs nearly as will as non-prejudiced but naive
intuition might imply...  Remember the first time you tried a real, LRU
scheme, was was very disappointed as to it's performance?  With the FreeBSD

in clock-type page replacement algorithms that approx. LRU ... pages
in storage are swept in a fixed order ... testing the (hardware) page
reference bit to see if it has been set since it was last reset
... and resetting the page reference bit. Pages that have been
touched/used since the last sweep that turned the referenced bit off
will not be selected for replacement ... pages that have not been
touched/used since the previous sweep (turning off the bit) will be
selected for replacement. Approx. to LRU is based on recently
used/touched pages will not be replaced.

There are various variations ... in systems with single hardware
reference bit ... the software can emulate multiple bits in software
... effectively "shifting" the value of a hardware bit into
software. Multiple bits then represent the settings of multiple sweeps
of resetting the bit (and longer reference history).

The problem with clock and other similar implementations approximating
LRU is that it degrades to FIFO under all sorts of conditions i.e. at
some point all pages have their reference bits on ... the test & reset
sweep thru all pages. At the end of that full sweep, all pages have
their reference bit off and the algorithm replaces the page it started
with. Then there is a very high probability that the next several
pages examined in the fixed order will continue to have their
reference bit off ... so the algorithm makes a sweep replacing several
pages in a fixed order.

THe '71 simulation work found that LRU appoximation algorithms as well
as simulated "true" LRU algorithm (across lots of different live load
trace data) found that LRU replacement frequently degenerated to FIFO
(LRU and FIFO were indistinquishable).

What was discovered was that with a minor coding hack ... CLOCK and
misc.  other LRU approximatins could be made to degenerate to nearly
RANDOM instead of degenerating to FIFO ... i.e. in the situations that
caused true LRU to degenerate to FIFO ... RANDOM replacement performed
much better than FIFO.

My line from '71 was something to the effect that if the algorithm
couldn't distinquish betweeen pages (effectively the situation where
nearly all page reference bits where all on or all off and led to LRU
replacement degenerating to FIFO) that it was better to choose pages
randomly for replacement than to choose pages for replacement in a
fixed order (FIFO).

In simulation, true LRU tended to avg. 10-15% better than the normal
CLOCK and other LRU approximation algorithms. The variation that had
LRU approximation degenerate to RANDOM tended on the avg. to be 10-15%
better than true LRU.

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

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Wed, 25 Oct 2000 15:02:43 GMT

Anne & Lynn Wheeler writes:

In simulation, true LRU tended to avg. 10-15% better than the normal
CLOCK and other LRU approximation algorithms. The variation that had
LRU approximation degenerate to RANDOM tended on the avg. to be 10-15%
better than true LRU.

aka ... in the portions of an operational envelope where LRU tended to
give good results, LRU was used ... when system shifted to portion of
the operational envelope where LRU was less well suited, RANDOM was
used.

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

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Wed, 25 Oct 2000 16:13:41 GMT

Anne & Lynn Wheeler writes:

in clock-type page replacement algorithms that approx. LRU ... pages
in storage are swept in a fixed order ... testing the (hardware) page
reference bit to see if it has been set since it was last reset

I had originally done clock-type alrogithms in the late 60s that
approximated global LRU and a dyanmica adaptive working set size.

In the literature at the time, there was stuff on fixed working set
size stuff with local LRU that executed on a fixed time basis.

The problems with what was in the literature was that it was
significantly sub-optimal, overhead was independant relationship to
contention and/or demand for pages, and didn't dynamicly adapt to
different configurations & load (amount of storage, replacement
latency, queuing delay, contention, etc).

The clock-type algorithms both dynamically adapted the overhead
processing and interval to demand/contention.

I was able to show that global LRU and adaptive working set size
significantly outperformed what was in the literature at the time.

http://www.garlic.com/~lynn/99.html#18
http://www.garlic.com/~lynn/93.html#4

In '71, I had somewhat accidently stumbled across LRU degenerating to
RANDOM instead of FIFO (and outperforming true LRU on the avg bas as
much as true LRU outperformed clock-like LRU approximations) when i
was trying various rearrangements of the clock code to make it much
more efficient in an SMP environment (reduce lock contention, etc with
multiple processors all contending for the page replacement
supervisor).

other random refs:

http://www.garlic.com/~lynn/94.html#49
http://www.garlic.com/~lynn/94.html#1
http://www.garlic.com/~lynn/93.html#7
http://www.garlic.com/~lynn/99.html#104
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/94.html#01
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/94.html#4
http://www.garlic.com/~lynn/94.html#10
http://www.garlic.com/~lynn/94.html#14
http://www.garlic.com/~lynn/93.html#6
http://www.garlic.com/~lynn/93.html#5

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

Why IBM use 31 bit addressing not 32 bit?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why IBM use 31 bit addressing not 32 bit?
Newsgroups: bit.listserv.ibm-main
Date: Wed, 25 Oct 2000 16:38:02 GMT

"Hank Murphy" writes:

Well, 31-bit addressing is, what - 17 years old now? - and it's hard to know
exactly why a designer did something that long ago.  However, the function
of bit zero is to carry the addressing mode (24 or 31) in the PSW and in the
24<->31 bit mode-switching instructions (BASSM, BSM).  It also allows one,
if sufficient discipline is exercised WRT the use of bits 0-7, to look at an
address constant and determine the mode.

the written design justifications for 31-bit instead of 32-bit (at the
time) had things like BXLE instructions where operands sometimes were
addresses and sometimes were signed integers i.e. BXLE typically was
used to both increment and decrement stepping thru things like arrays
(aka difficulties doing signed interger operation on a unsigned 32-bit
number).

the 370/etc princ-of-ops was a script/gml document that was a subset
of the architecture "red-book". The architecture "red-book" had a
bunch of "conditional" sections that gave a lot of justification &
trade-offs of why things were done they way they were.

For instance, t\he original 370 architecture "red-book" gave a
complete virtual memory and addressing architecture (before virtual
memory was announced). Coming up on the time to announce 370 virtual
memory ... there was a big battle over what would be announced and
shipped. Both the 155s & 165s in the field needed significant hardware
upgrade to support relocation. One of the points finally came down to
announcing & releasing the full 370 virtual memory architecture (as
embodied in the red-book) would take a significant additional redesign
and rewire of the virtual memory retrofit for the 165 delaying the
virtual memory announcement by six months.

There was various escalation meetings with all parties concerned and
finally it was decided to go with a subset of 370 virtual memory
architecture. One of the deciding factors was that the POK SVS group
stated that SVS only had a single address space and customer
installations would peak at max. of five page I/O per second and
therefor the additional features would see no benefit in a SVS
environment.

random refs:

http://www.garlic.com/~lynn/93.html#14
http://www.garlic.com/~lynn/2000c.html#84
http://www.garlic.com/~lynn/2000e.html#57

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

Optimal replacement Algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Optimal replacement Algorithm
Newsgroups: comp.arch
Date: Wed, 25 Oct 2000 20:57:55 GMT

toor@y1.jdyson.net (John S. Dyson) writes:

The FreeBSD scheme isn't perfect, but appears to be very good for
real loads (including both sequential and stats that have
ARBITRARY skewed distributions.)  There are no assumptions as to
the usage distributions, unlike in the clock scheme.  The adapation
to the kind-of distribution is automatic in the FreeBSD scheme.  The
FreeBSD scheme doesn't depend on a gaussian or address correlated
paging stats.

yep, did a lot of stuff about thrashing controls with multiprogramming
level ... global LUR vis-a-vis local LRU ... i.e. nominally global LRU
replacement but for really ill-behaving applications ... could switch
to local LRU (or some called it "self-stealing").

when i got to ship some of this stuff in products ... I had the
benefit of a lot of work by others in simulation plus workload
profiling that had been collected across hundreds of different
configurations & loads over a period of a number of years.

As a result was able to construct some synthetic benchmarks that could
be configured along the edges of the configuration/load envelopes,
statistical points within the nominal configuration/load envelope, and
various severe outlyers ... way beyond the edge of observed
configuration/load envelopes.

Several thousand synthetic benchmarks was then devised that covered
the observed configuration/load envelope (interior, boundary
conditions, extreme outlyers, etc) that took three months elapsed time
to execute.

The information was then used to validate all kinds of stuff I was
doing in dynamic adaptive & feedback/feedforward stuff across a broad
range of different configurations & loads ... not just page
replacement, but various thrashing controls, scheduling and
dispatching controls, "scheduling to the bottleneck" adaptation,
etc. Scheduling to the bottleneck attempting to identify the
bottleneck thruput resources and adjust scheduling based on the
consumption of bottleneck resources (which might or might not be cpu
or storage or i/o or page i/o, etc).

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

OT?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 03 Nov 2000 05:43:03 GMT

Anne & Lynn Wheeler writes:

In the late '60s Les transferred to Wash DC. During FS he was head of
the inter-system coupling section/area in FS. My wife worked for
him. After FS was shutdown, my wife spent some time working on
JES2/JES3 in g'burg and then went to POK to be responsible for
loosely-coupled architecture. She did peer-coupled shared data
architecture and fought for things like making trouter/3088 more than
just CTCA.

some clarification from anne ... g'burg was responsible for FS
I/O. Les was responsible for FS Advanced I/O Architecture.

Instruction source/destination operands had various attributes
(possibly 3-5 levels of attributes). The FS microcode was responsible
for doing the magical DWIM based on the attributes. Source/Destination
operands with attributes associated with I/O was much less well
defined for the microcode "do what i mean" magic (than most other parts
of the FS architecture)

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

Ethernet efficiency (was Re: Ms employees begging for food)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet efficiency (was Re: Ms employees begging for food)
Newsgroups: comp.os.linux.advocacy,comp.os.ms-windows.nt.advocacy,comp.arch,comp.os.netware.misc
Date: Fri, 03 Nov 2000 13:35:06 GMT

Lars Poulsen writes:

The notion that as ethernet wire utilization goes up, the throughput
peaks at about 30% and after that it becomes an unproductive mess
of collisions is common but incorrect. It is rooted in the assumption
that collisions are bad, abnormal things, and that once utilization
goes up, the retransmission is likely to collide again. Both of those
beliefs are wrong. THAT IS NOT HOW ETHERNET WORKS.

There was a paper in (i believe) '88 acm sigcomm procedings that
showed for a typical hub twisted-pair with 30 concurrent machines, all
in a solid low-level loop continuously transmitting minimum sized
packets that effective thruput dropped to 8.5mbits/sec. Ethernet is
listen before transmit with collision detection afterwards (same
procedings also had paper showing slow-start non-stable in real-world
environments).

There was a 3mbit/sec early '80s version that didn't listen before
transmit. Analytical modeling of a 3mbit thick-net (w/o listen before
transmit) with several hundred stations I believe showed efficiencies
dropping below 30%. Part of this was due to lack of listen before
transmit. Probability of collisions was purely based on amount of
contention.

With listen before transmit, collisions become function of both
contention and network transmission latency. Worst case in thin/thick
net were/are the stations at the futherst ends of the cable (and total
distance/latency is somewhat proportional to number of stations since
it is the sum of all the segments).

Hub-based twisted pair tends to better bound the worst case latency
because it is proportional to the two longest segments and independant
of the number of segments.

I got into deep dudo including twisted-pair solutions when I
introduced 3-layer architecture to IS executives of large
multinational corporation. The 16mbit T/R guys had been using a
analytical model with 3mbit/sec ethernet w/o listen before transmit &
comparing it to 16mbit T/R (and showing around 1mbit/sec ethernet
effective thruput). Quoting the sigcomm paper made T/R guys even less
happy.

random refs:

http://www.garlic.com/~lynn/2000e.html#45
http://www.garlic.com/~lynn/2000b.html#11
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/94.html#22

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

Ethernet efficiency (was Re: Ms employees begging for food)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet efficiency (was Re: Ms employees begging for food)
Newsgroups: comp.os.linux.advocacy,comp.os.ms-windows.nt.advocacy,comp.arch,comp.os.netware.misc
Date: Fri, 03 Nov 2000 14:35:43 GMT

found the reference

"Measured Capacity of Ethernet: Myths and Reality" in proceedings of
ACM SIGCOMM, 8/16-19, 1988, V18N4

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

Famous Machines and Software that didn't

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Famous Machines and Software that didn't
Newsgroups: alt.folklore.computers
Date: Sat, 04 Nov 2000 00:13:56 GMT

"David C. Barber" writes:

o    IBM FS: The Future System I recall hearing of for awhile, but don't
recall the details.  Hopefully someone can provide them.  I was very new in
computers at the time.

this was recently raised on ibm-main mailining list.

random refs:

http://www.garlic.com/~lynn/2000f.html#16
http://www.garlic.com/~lynn/2000f.html#17
http://www.garlic.com/~lynn/2000f.html#18
http://www.garlic.com/~lynn/2000f.html#19
http://www.garlic.com/~lynn/2000f.html#26
http://www.garlic.com/~lynn/2000f.html#27
http://www.garlic.com/~lynn/2000f.html#28
http://www.garlic.com/~lynn/2000f.html#29
http://www.garlic.com/~lynn/2000f.html#30
http://www.garlic.com/~lynn/2000f.html#31
http://www.garlic.com/~lynn/2000f.html#37

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

Reason Japanese cars are assembled in the US (was Re: American bigotry)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Reason Japanese cars are assembled in the US (was Re: American bigotry)
Newsgroups: alt.folklore.military,rec.autos.driving,alt.autos.honda,rec.autos.makers.toyota,rec.autos.makers.honda
Date: Sun, 05 Nov 2000 15:12:08 GMT

"edward_ohare" writes:

There were some thoughts that higher US costs were largely due to higher
health care costs and because the US used a higher percentage of its
industrial and engineering capacity to build military equipment than Japan
did.

I believe that there was an article in the Wash. Post in the late '70s
calling for an unearned profits tax on the US automobile industry.
Supposedly before the quotas, avg.  US car price was around $6k & the
purpose of the quotas was to give the US industry additional profits
so that it could remake itself. With the quotas, Japanese car makers
realized that they could sell as many luxuary cars as they could sell
"cheap" cars. Both the quotas and the shift in (Japanese) product
supposedly allowed the US industry to increase the avg. price over a
relatively short period to $13k. The point of the article was that
represented greater than billion dollars in increased profits which
appeared to all go to executives and shareholders ... and they found
no evidence any was re-invested in making the industry more
competitive.

In the late '80s, the industry did finally take a better crack at
reinventing itself. For instance, up until then the avg. development
cycle time in the US for a new product was approx. seven years (from
concept to delivery). The Japanese had shorten that to three years for
the lexus, infinity, etc, products. The result was that the Japanese
could adapt nearly two & half times faster to changing customer
circumstances (than the US). The C4(?) project helped turn out the
initial S10 in three years and also supposedly vastly improved
quality.

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

IBM 3340 help

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 3340 help
Newsgroups: alt.folklore.computers
Date: Mon, 06 Nov 2000 20:34:26 GMT

John Ferrell writes:

The DASD sub system operated through more than one control device. The
interface under test needed to be selected, because the diagnostics were not
multipath capable. There was at least one OS that gave only one warning of
dropping a path. A dead path could go undetected if the operator missed the
message.

33xx "string switch" allowed a string of disks to be connected to two
different control units (3830 & 3880 controller could connect to four
different channels, a "string" of disks connected to two different
controllers allowed disk connectivity attachment for up to eight
different channels/processors).

I remember 3380s coming in A & B boxes ... where (I think) "A" boxes
where "head of string" and contained the logic allowing attachment to
multiple controllers (an "A" box and three "B" boxes for 16 drives in
a string?).

The I/O architecture had misc problems with string switches. Standard
architecture provided for channel-busy, controller-busy, and
device-busy indications. String-switch wasn't a resource concept
provided for in the i/o architecture ... so string-switch effectively
used multiple device-busies to simulate a string-switch busy.

Data transfers & things like search operations would "busy" shared
resources (i.e. channel, controller, string-switch). Any device in a
string doing something like a multi-track search (worst case about 1/3
sec. for a 3330) would cause the related string-switch to be busy and
all other devices (i.e. up to 15) on the same string to be unavailable
(regardless of additional controllers or channels).

random refs (alta vista)

http://www.storagetek.com/State_of_Texas/item_code_non_93921/3370_307.html
http://web.archive.org/web/20010107165600/http://www.ecole.org/Report_IBM.htm

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

Reason Japanese cars are assembled in the US (was Re: American bigotry)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Reason Japanese cars are assembled in the US (was Re: American bigotry)
Newsgroups: alt.folklore.military,rec.autos.driving,alt.autos.honda,rec.autos.makers.honda
Date: Mon, 06 Nov 2000 23:49:41 GMT

"edward_ohare" writes:

The Chrysler LH cars hit the street 22 months after they decided to build
them, and that was for a car which shared few parst with previous designs.

During the trade restrictions, Ford made heavy investment in front wheel
drive, converting all their high volume lines from rear to front drive.  So
did GM.  Toyota in particular lagged behind in moving to front wheel drive.

There is no doubt the US was at a competitive disadvantage, but not all this
can be blamed on the auto industry.  The US has for 55 years incurred the
expense of protecting Japan's sources of oil and ores needed for its
industry, at no cost to Japan except for the indignity of being treated like
a protectorate.

What if a bunch of the engineers who worked for military contractors were
instead working for US auto makers?

Must of been having a senior momemt, wash post article on unearned
profits had to have been early '80s not late '70s.

I only saw some of the C4 stuff at GM and didn't really see the other
manufactures.  However, with seven year cycle, you would tend to have
2-3 concurrent overlapping efforts with staggered offset of 2-4 years
so new products were coming to market on more frequent bases. Also,
early in a cycle, you might have two or more competing teams since
predictions out seven years could be open to interpretation and you
would want to cover contingencies. Moving from 7 year cycle to 3 year
cycle might result in 80% reduction in the number of required
engineers (competitive forces w/military for the top 10-50 engineers
in the country could still be a factor tho).

I do know that i bought a malibu for over $5k in '76 and it was around
$13k something like 8 years later (and that represented closer to the
avg. price of US car sold). Of course, inflation accounted for some of
the change but I think that during this period, finance periods
increased from 3 year to 5 year (possible indication of prices
increasing faster than wages, also would have helped precipitated the
5 year warrenties that started to show up in the early '80s).

C4 addressed radical changes in the end-to-end process ... not so much
what was being done ... but how they went about doing it (as well as
the cost of doing it). Drastic reductions in cost/time also implied
reductions in number of people. I would expect that just quantity of
engineers would tend to result in longer cycles, larger number of
different models and fewer common components.

One example given C4 was corvette design because the skin/surface done
by the designers tended to have tight volume tolerances. Seven year
cycle resulted in several re-engineering & re-design activities
because of minor modifications of basic components done by other
divisions and/or suppliers (change in delco battery during the cycle
required modifications to the exterior surface).

With respect to foriegn exchange in one of the following refs, I
remember being in tokyo when exchange rate was 300/$ and since seen it
drop below 100/$ (the relative cost of their products in the US market
increased by a factor of 3 over a period of 25-30 years).

In some of the following there are references to a benefit of the
purchase of AMC to Chrysler because AMC had already started takeup of
Honda/Japanese manufacturing techniques.

misc. refs:

http://www.media.chrysler.com/wwwhome/hist.htm
http://web.archive.org/web/20010204034500/http://www.media.chrysler.com/wwwhome/hist.htm
http://www.inu.net/davidstua/chrysler_case_part1.htm
http://web.archive.org/web/20010222205419/http://www.inu.net/davidstua/chrysler_case_part1.htm
http://www.michiganinbrief.org/text/appendix/append-J.htm
http://web.archive.org/web/20010217003458/http://www.michiganinbrief.org/text/appendix/append-J.htm
http://mrtraffic.com/millennium.htm
http://www.sbaer.uca.edu/docs/proceedingsII/97sma228.txt
http://web.archive.org/web/20000829050939/http://www.sbaer.uca.edu/docs/proceedingsII/97sma228.txt
http://www.rindsig.dk/viden/3-sem/Rising-sun.html
http://web.archive.org/web/20010222203823/http://www.rindsig.dk/viden/3-sem/Rising-sun.html
http://www.iitf.nist.gov/documents/committee/cat/breaking_barriers_conf.html
http://web.archive.org/web/20010104022000/http://www.iitf.nist.gov/documents/committee/cat/breaking_barriers_conf.html

from the above iitf/nist ref:

General Motors took a different tack by replacing the dissimilar
hardware and software that existed throughout the corporation and
creating an integrated system known as C4 (computer-aided design,
computer-aided manufacturing, computer-integrated manufacturing and
computer-aided engineering). As part of its C4 program, GM linked the
design, manufacturing and assembly teams that were previously unable
to communicate with each other. GM made the decision that although its
legacy systems represented a sizable capital investment, it was
important that the entire manufacturing process be overhauled to
ensure interoperability and interconnectivity among all the players on
the new network, including suppliers.

http://www-personal.umich.edu/~afuah/cases/case3.html

misc pieces from the above

The Rise of Foreign Competition (1970-1980)

By the early 1970s American automakers were facing strong global
competition both at home and abroad. Japanese automakers in particular
made a significant impact on the industry by introducing smaller, less
expensive, and more fuel-efficient cars to the American market. This
coincided with the oil crisis, which resulted in higher gasoline
prices and a shift in consumer tastes toward greater fuel
efficiency. Other advantages of the Japanese automakers resulted from
their use of just-in-time (JIT) inventory controls, modern
manufacturing techniques, and quality control and management
practices.

By 1980, American carmakers had lost about one-fourth of the fastest
growing segment of the domestic market - small cars - to Japanese
producers. In response to pressure from the United States government,
Japanese automobile producers implemented voluntary export restraints
(VER) on their auto exports to United States. This VER agreement
limited Japanese imports to not more than 1.68 million vehicles per
year.

Restructuring of American Automobile Production (1980-1990)

While under the limitation of VER in the early 1980s, Japanese (and
other) automobile companies shifted their strategies to foreign direct
investment, setting up new facilities to produce cars locally in
United States. Leaders were Honda, Mazda, Nissan, and Toyota, which
collectively invested $5.3 billion in North American-based automobile
assembly plants between 1982 and 1991.2 This was viewed as a response
to VER - the Japanese automobile firms wanted to circumvent the threat
of protectionist trade legislation. However, it was also a response to
higher production costs at home and the sharp rise in the value of the
Japanese Yen against the U.S. dollar during 1987, which dramatically
increased the cost of exporting both automobiles and component parts
from Japan to other markets.

To halt further erosion of their position, protect their remaining
share of the domestic market, and prepare for competition in the
global economy, the American automakers implemented programs to
duplicate the world's best manufacturing practices. This included
efforts to apply Japanese-style manufacturing practices such as JIT
inventory control and leaner production systems to reduce costs. Yet,
there were still important differences.

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

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: comp.society.futures,alt.folklore.computers
Date: Tue, 07 Nov 2000 04:05:25 GMT

rh120@konichiwa.cc.columbia.edu (Ronda Hauben) writes:

The NREN initiative was being discussed in the early 1990's.
It claimed it would be support for a research and education networking
inititive.

That initiative somehow disappeared, and instead the NSFNET (the backbone
of the Internet in the US) was given to private interests.

A major change in Internet policy was made without any public
discussion of why this would be desirable. And it was done at
a time when there was officially the claim there would be support
for a research and education network.

The only public discussion that seems to have been held about
this happening was the online NTIA conference held by the
U.S. Dept of Commerce in November 1994. During this conference
there were many people explaining why it was not appropriate to
privatize the public US backbone to the Internet.

note that the NSFNET1 & NSFNET2 contracts were for very specific $$$
and point-to-point links between a relatively small number of
locations. By the early 90s, the non-NSFNET portions of the internet
was couple hundred times larger than the NSFNET portions. Based on
principles like efficiency of scale, COTS, etc ... it would have made
sense to transition the relative modest NSFNET pieces to the
commercial internet.

Also, there was extensive drive in the early '90s to get programs off
the gov. dole, extensive incentive to get gov. contractors to find
commercial funding/ooutlets for large portions of their activities,
migration to COTS offerings and other initiatives (ARPA's TRP
technology reinvestment program, startup funding to migrate all possible
gov. developed technologies into commercial sector; NIST ATP
... advanced technology program, NASA AITP, etc)

NSFNET was in large respect to demonstrate feasability of high-speed
service offering. Once that was demonstrated, it would have consistant
with all the other technology activities of the period to transition
to COTS/commercial offerrings.

Other instances were a number of conferences in the early to mid-90s
where the national labs were attempting to "sell" a lot of technology
to the medical industry.

There use to be lots of technology reuse program references on the web
current alta-vista search turns up

http://www.stanford.edu/group/scip/sirp/US-NII-slides.html

"ARPA TRP" turns up a few more ... sample

http://www.eng.auburn.edu/~ding/emc/emc.html
http://web.archive.org/web/20010222212533/http://www.eng.auburn.edu/~ding/emc/emc.html
http://sebulba.mindtel.com/21698/nasa/ames.html
http://web.archive.org/web/20010225040040/www.quasar.org/21698/nasa/ames.html
http://www.uscar.org/pngv/progplan/9_0.htm
http://web.archive.org/web/20010217102712/http://www.uscar.org/pngv/progplan/9_0.htm
http://me.mit.edu/groups/lmp/industry.htm
http://logic.stanford.edu/cit/commercenet.html

including

http://nii.nist.gov/cat/tp/t940707.html
http://web.archive.org/web/20010222211057/http://nii.nist.gov/cat/tp/t940707.html

the following from the above

Information Infrastructure Project (IIP)

Brian explained that the IIP is part of the Kennedy School's Science,
Technology and Public Policy Program, which is directed by Lewis
Branscomb. IIP began in 1990 addressing issues in the
commercialization of the Internet and the development of the NREN. It
now encompasses a wide variety issues related to the NII.

IIP addresses issues by bringing together experts in an
interdisciplinary setting. Strategies to protect intellectual
property, industrial extension networking, CALS, public access to the
Internet, and standards are some of the topics that have been
addressed. Brian's group publishes quarterly, a two-volume Information
Infrastructure Sourcebook. The project also runs the Information
Infrastructure Forum, which is hosted in Washington by the Annenberg
Washington Program.  This year they have held fora on competition
policy, interoperability, and enabling interconnection -- and next,
long term economic issues.

for "NIST ATP", alta vista turns up maximum number (20pages/200)

federal technology transfer web site:

http://www.federallabs.org/

technology transfer legislative history web site (going back to 1980)

http://www.dtic.mil/techtransit/refroom/laws/

some of the entries from above

Small Business Technology Transfer (STTR) Program 1992 (PL 102-564)

     Established a 3 year pilot program - Small Business Technology Transfer
     (STTR), at DoD, DoE, HHS, NASA, and NSF.
     Directed the Small Business Administration (SBA) to oversee and
     coordinate the implementation of the STTR Program.
     Designed the STTR similar to the Small Business Innovation Research
     SBIR program.
     Required each of the five agencies to fund cooperative R&D projects
     involving a small company and a researcher at a university,
     federally-funded research and development center, or nonprofit research
     center.

National Department of Defense Authorization Act for 1993 (PL 102-25)

     Facilitated and encouraged technology transfer to small businesses.

National Department of Defense Authorization Act for FY 1993 (PL 102-484)

     Established the DoD Office of Technology Transition
     Extended the streamlining of small business technology transfer
     procedures for non-federal laboratory contractors.
     Directed DoE to issue guidelines to facilitate technology transfer to small
     businesses.
     Extended the potential for CRADAs to some DoD-funded Federally Funded
     Research and Development Centers (FFRDCs) not owned by the
     government.

National Department of Defense Authorization Act for 1994 (PL 103-160)

     Broadened the definition of a laboratory to include weapons production
     facilities of the DoE.

National Technology Transfer and Advancement Act of 1995 (PL 104-113) [also
known as the "Morella Act"]

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

Al Gore and the Internet (Part 2 of 2)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Al Gore and the Internet (Part 2 of 2)
Newsgroups: comp.society.futures,alt.folklore.computers
Date: Tue, 07 Nov 2000 15:45:19 GMT

Anne & Lynn Wheeler writes:

http://www.federallabs.org/

technology transfer legislative history web site (going back to 1980)

http://www.dtic.mil/techtransit/refroom/laws/

misc entries from the federal technology transfer web site ...  with
respect to the organization:

The Federal Laboratory Consortium for Technology Transfer (FLC) was
organized in 1974 and formally chartered by the Federal Technology
Transfer Act of 1986 to promote and to strengthen technology
transfer nationwide. Today, more than 700 major federal laboratories
and centers and their parent departments and agencies are FLC
members.

sample listing of technology transfer success stories is at:

http://www.federallabs.org/servlet/LinkAreaFramesetServlet?LnArID=SuccessStories&LnArRegion=National

one of the "stories" titled "The Great Government Giveaway"

http://www.businessweek.com/smallbiz/0006/te3685116.htm
http://web.archive.org/web/20010109054800/http://www.businessweek.com/smallbiz/0006/te3685116.htm

and a couple more entries from the legislative history web site ...

Stevenson-Wydler Technology Innovation Act of 1980 (PL 96-480)[15 USC
3701-3714]

     Focused on dissemination of information.
     Required Federal Laboratories to take an active role in technical cooperation.
     Established Offices of Research and Technology Application at major federal
     laboratories.
     Established the Center for the Utilization of Federal Technology (in the National
     Technical Information Service).

Bayh-Dole Act of 1980 (PL 96-517)

     Permitted universities, not-for-profits, and small businesses to obtain title
     to inventions developed with governmental support.
     Provided early on intellectual property rights protection of invention
     descriptions from public dissemination and FOIA.
     Allowed government-owned, government-operated (GOCO) laboratories
     to grant exclusive licenses to