List of Archived Posts

2007 Newsgroup Postings (05/25 - 06/09)

John W. Backus, 82, Fortran developer, dies

The top 10 dead (or dying) computer skills

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

IBM Unionization

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

My Dream PC -- Chip-Based

My Dream PC -- Chip-Based

Superconductors and computing

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

Linux: The Completely Fair Scheduler

Non-Standard Mainframe Language?

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

Non-Standard Mainframe Language?

U.S. Cedes Top Spot in Global IT Competitiveness

John W. Backus, 82, Fortran developer, dies

Is Parallel Programming Just Too Hard?

Computer tube production years

Is Parallel Programming Just Too Hard?

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

tab browsing

John W. Backus, 82, Fortran developer, dies

Virtual private networks

John W. Backus, 82, Fortran developer, dies

Is Parallel Programming Just Too Hard?

My Dream PC -- Chip-Based

Questions to the list

Friday musings on the future of 3270 applications

Is Parallel Programming Just Too Hard?

My Dream PC -- Chip-Based

My Dream PC -- Chip-Based

My Dream PC -- Chip-Based

My Dream PC -- Chip-Based

My Dream PC -- Chip-Based

internet game history

internet game history

My Dream PC -- Chip-Based

My Dream PC -- Chip-Based

My Dream PC -- Chip-Based

Drums: Memory or Peripheral?

Scholars needed to build a computer history bibliography

Scholars needed to build a computer history bibliography

Drums: Memory or Peripheral?

Drums: Memory or Peripheral?

Newbie question on table design

Scholars needed to build a computer history bibliography

Scholars needed to build a computer history bibliography

How would a relational operating system look like?

Scholars needed to build a computer history bibliography

Scholars needed to build a computer history bibliography

Is Parallel Programming Just Too Hard?

John W. Backus, 82, Fortran developer, dies

Friday musings on the future of 3270 applications

Is Parallel Programming Just Too Hard?

John W. Backus, 82, Fortran developer, dies

mainframe = superserver

BAH's Point of View

nouns and adjectives

nouns and adjectives

nouns and adjectives

nouns and adjectives

IBM 360 Model 20 Questions

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Fri, 25 May 2007 16:57:12 -0600

Charlton Wilbur <cwilbur@chromatico.net> writes:

The ways for this to break are for someone to compromise Verisign's
infrastructure, which means that they can sign cryptographic
certificates as Verisign; for someone to be colluding with Verisign
for fraud, which means that Verisign will sign cryptographic
certificates for them even when the signature is fraudulent; or to
hack into my computer and replace the certificate authority keys in my
web browsers.

there are lots of other attack vectors, for some of the discussion:
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies

so one of the ideas behind public/private key business process ... is
that the relying-party/recipient has a local repository of trusted
public keys. any communication they get that has been digitally signed,
the recepient verifies the digital signature with a public key from
their local trusted public key repository.

the PKI certification authority industry expanded this for the scenario
where 1) you have first time communication with stranger you have never
communicated with before, 2) you don't have their public key in your
trusted public key resposotory, and 3) you have no way of doing timely,
online direct communication with a trusted certification institution to
obtain information about this stranger.

so your trusted public key respository is preloaded with the public keys
of a bunch of trusted "certification authorities" ... these
certification authorities, certify the public keys of "strangers", and
issue than a digitally signed certificate (representing that
certification). now relying-party/clients can verify the digital
signature on a certificate (using certification authority public key
from their local trusted public key repository) ... and then trust the
public key included in the digital certificate. This is basically a
one-level indirection from the basic design where you have trusted
public keys of the entities you are directly communicating with ... now
you have trusted public keys of the certifying authorities ... which
indirectly get you trusted public keys of the strangers that you are
having first time communication.

So one of the first vulnerabilities ... is all the public keys in your
local trusted public key repository are treated equally. You don't have
to subvert the public key of a particular certification authority, all
you have to do is subvert any of the possibly 40-50 public keys (in the
repository) belonging to any certification authority. Another attack is
a virus/trojan that is able to add a new public key to the respository.
The way the mechanism work is that there just has to be at least one
compromised public key in the client's trusted public key repository.

Another succesful attack scenario is things like domain name hijacking.
Part of the whole original SSL stuff was to address some perceived
vulnerabilities in the domain name infrastructure. The issue is that the
certification of a domain name (represented by a digital certificate) is
countermeasure to perceived weaknesses in the domain name
infrastructure.

The problem is that all the domain name certification authorities have
to check with the domain name infrastructure as to the true owner of a
domain ... when they are processing an application for a SSL domain name
digital certificate. This is a time-consuming, error prone, and
expensive identification process to match the SSL domain name digital
certificate applicant with the information on file with the domain name
infrastructure as to the owner of the domain name. Now an interesting
fact, the effective "trust root" for SSL certificates ... is the domain
name infrastructure ... the very same domain name infrastructure that
has integrity issues justifying the existance of SSL certificates.  Any
problem in any domain name infrastructure and/or any certification
authority might result in the issuing of a valid SSL digital certificate
to an incorrect/fraudulent party.

So there is something of a catch-22 for the SSL domain name
certification authority industry ... lots of past discussions
http://www.garlic.com/~lynn/subpubkey.html#catch22

Part of DNSSEC to improve the integrity of the domain name
infrastructure is for things like requiring domain name owners to have
an onfile public key with the domain name infrastructure. Improving the
integrity of the domain name infrastructure is both

1) in the interests of the certification authority industry because it
lessons the probability of domain name hijacking and crooked applicant
being issued a valid digital certificate

2) not in the interest of the certification authority industry because
improvements in the domain name infrastructure integrity negates the
original justification for having SSL domain name certificates.

Another part of the catch-22 is if the domain name
infrastructure can require all communication to be digitally signed
(which they can verify with the "onfile" public key; direct public
key, no digital certificate required) .... then it is possible that
the certification authority could also. Requiring all SSL domain name
certification applications to be digitally signed means that the
certification authority can do a real-time, online retrieval of the
onfile public key to verify the signature (no digital certificate
required) and change a time-consuming, expensive, and error prone
identification processing into a significantly simpler, less
expensive, and more reliable authentication process.

The problem is that if both the domain name infrastructure and the
certification authority industry can start using real-time, online
retrieval of certificate-less public keys ... then the rest of the world
might be able to also. Some discussions of certificate-less public key
operation
http://www.garlic.com/~lynn/subpubkey.html#certless

Improving the integrity of the domain name infrastructure goes a long
way of negating the original justification for having SSL domain name
certification (and the associated digital certificates). Being able to
do trusted real-time, online retrieval of public keys then finishes
making the SSL domain name digital certificates obsolete, redundant
and superfluous.

A big part of the problem is that the certification authority industry
are dependent on the integrity of the domain name infrastructure as to
the true owner of the domain name (in determining who will and will
not be issued digital certificates for a domain). However, the
certification authority industry is also dependent on the lack of
integrity of the domain name infrastructure as the justification for
having SSL domain name certificates. lots of past SSL and/or
SSL digital certificate posts
http://www.garlic.com/~lynn/subpubkey.html#sslcert

recent posts on the subject:
http://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardised Security Protocols are Too Heavy
http://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardised Security Protocols are Too Heavy
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored

The top 10 dead (or dying) computer skills

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The top 10 dead (or dying) computer skills
Newsgroups: alt.folklore.computers
Date: Fri, 25 May 2007 19:51:44 -0600

Steve O'Hara-Smith <steveo@eircom.net> writes:

I remember the event well - it did happen briefly a long time ago.
I overstated slightly though, the kernel build switched to using C++ with
the announced intention of moving some of the kernel code to C++ it was
backed out on the next release. This was some time before 1.0.

the whole object oriented craze ... apple was going to have (object
oriented) pink as its next operating system ... and sun was going to
have spring.

pink floundered ... although some of the object oriented technology
lived on for awhile in taligent. instead apple moved to the (CMU) MACH
microkernel (also had been used in NeXT).

spring also foundered ... although i've had some discussions about
whether some of it influenced JAVA (i.e. spring had a small footprint
interpreter for client machines supporting efficiency of downloading
applications). at one point we got polled if we would be interested in
heading up a project to do the industrial strength stuff to get spring
out the door.

old posts mentioning pink, spring, taligent, etc
http://www.garlic.com/~lynn/2000.html#10 Taligent
http://www.garlic.com/~lynn/2000e.html#42 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2000e.html#48 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2001j.html#32 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001j.html#36 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002i.html#60 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002j.html#76 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002m.html#60 The next big things that weren't
http://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#47 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003e.html#28 A Speculative question
http://www.garlic.com/~lynn/2003e.html#51 A Speculative question
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#14 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005f.html#38 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2007g.html#69 The Perfect Computer - 36 bits?

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 26 May 2007 07:38:04 -0600

jmfbahciv writes:

Wonderful.  Is this going to change or will laws have to be passed
in each and every country?
<snip>

Thank you.  My instinct of paranoia was correct.

re:
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#0 John W. Backus, 82, Fortran developer, dies

there are other issues. normal business practices has some sort of
contractual relationship/obligation between two parties ...  i.e. the
relying party ... that is receiving a digital signature (with an
appended digital certificate) and the party generating the digital
signature (and has appended the digital certificate).

the term relying party, comes from the party that is relying on the
"certified" information contained in a digital certificate.

many standard PKI and digital certificates ... essentially violate
standard business model and business practices ... because there is
frequently no contractual and/or business relationship between the
relying party and the certification authority (no exchange of value or
money) ... and therefor any basis for establishing reliance and/or
liability.

the federal government PKI has gotten around the problem of lack of any
normal business practices by having the GSA (representing the federal
gov. as the relying party) sign a contract with each of the authorized
certification authorities. The certification authorities then certify
various individual information and place that certified information in a
digitally signed digital certification. When individuals digitally sign
communication sent to the federal gov and attach a digital certificate,
the relying party (the federal gov.) has a valid contract and business
justification to "rely" on the certified information.

The normal practice with SSL domain name certificates ... has at least
an implied contract between merchant webservers and certification
authorities ... since the webserver has paid money to the certification
authority.  However, clients that use SSL to connect to the webserver
... and are therefor the relying party for the presented digital
certificate ... have no explicit, implicit and/or implied contract with
the certification authority ... and therefor no "grounds" for
estalishing any legal reliance or obligation between the certification
authority and the clients as relying parties. This is in addition to any
disclaimers by certification authorities with reqard to liability and/or
obligation ... aka there is no legal reason for clients (as relying
parties) to believe that they can rely on the information in such
digital certificates (since there is no business or legal obligation to
base such a claim). In general, most "trusted 3rd party" PKI operations
don't conform to any standard, traditional business and/or legal
practices.

There is another issue, that there frequently appears to be semantic
confusion because the term human signature and the term digital
signature both contain the word signature ... which can create the
impression that a digital signature can somehow be analogous to a
human signature. We had been brought in to help word smith the
cal. state electronic signature legislation (and later the federal
electronic signature legislation). some posts discussing the activity
http://www.garlic.com/~lynn/subpubkey.html#signature

There was some lobbying attempting to have gov. mandates that electronic
signatures were digital signatures and would have required appended
digital certificates from a designated/authorized certification
authority.  However, some of the business lawyers present pointed out
that both standard digital signature process and any possible appended
digital certificates failed to meet requirement for human signatures
involving indidication that a human had read, understood, agrees,
approves, and/or authorizes what has been "signed".

Neither digital signatures ... and/or any appended digital certificate
(which may have generated at some point far in the past, along with any
certifying operations) carried with it any implication of human intent
... and/or the action of having read, understood, agrees, approves,
and/or authorizes.

basic "digital signature" provides "authentication" and "integrity"
business processes ... but fails to satisfy any conditions related to
human intent and/or having read, understood, agrees, approves, and/or
authorizes.

There is further possible compromises/exploits when digital signatures
get confused with having read, understood, agrees, approves, and/or
authorizes. In most cases, a human hasn't actually physically examined
the bits for which a digital signature may get generated (i.e. fails to
even meet "read/understood" requirement).

A typical scenario is a PKI digital signature "authentication" protocol
(which might be used in place of userid/password scenario). The server
sends the client some "random data" (as countermeasure to login replay
attack) to be digitally signed. The client's computer would typically
digitally sign the transmitted data (random and changes on every use ...
so attacker couldn't evesdrop the exchange and replay it later) and
returns the digital signature to the server. The server then can
"authenticate" the client by validating the digital signature with the
client's public key.

Now, if there ever was the mischance of also confusing digital signature
with human signature ... and having individuals digital sign something
... creating obligation that the individual has read, understood,
agrees, approves, and/or authorizes what had been digitally signed ...
there is a dual-use attack opening. Somebody compromises some server,
somplace in the world ... and substitutes valid transactions and/or
contracts for the authentication protocol "random data" ... and starts
to collect large number of legal, digitally signed
contracts/obligations.

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

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 26 May 2007 07:57:52 -0600

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

There is another issue, that there frequently appears to
be semantic confusion because the term human signature
and the term digital signature both contain the
word signature ... which can create the impression that
a digital signature can somehow be analogous to a
human signature. We had been brought in to help word smith the
cal. state electronic signature legislation (and later the federal
electronic signature legislation). some posts discussing the activity
http://www.garlic.com/~lynn/subpubkey.html#signature

re:
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#0 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies

disclaimer ... although we no longer have any affiliation with the
patents, ... we did some work on how to establish an infrastructure
where operations performed by a device generating digital signatures
could meet the requirements for human signature ... aka
demonstration of intent, having read, understood, agrees,
approves, and/or authorizes.
http://www.garlic.com/~lynn/x959.html#aads

other posts having been brought in to help word-smith electronic
signature legislation.
http://www.garlic.com/~lynn/subpubkey.html#signature

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 26 May 2007 08:33:38 -0600

jmfbahciv writes:

And you don't have to move the Windows installation at all?  I was
assuming that there something in the equivalent of the BIOS
that triggered which way the system goes.

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

BIOS settings selects order in which devices are tested for
booting.

BIOS will look and boot from specific hard disk partition
based on settings on the hard disk

software is available to reorganization existing filesystems and hard
disk partititions; changing which partition that BIOS should boot from,
shrinking/enlarging existing partitions, making new partitions, etc.
aka if there isn't unallocated/spare partition, shrink an existing
windows partition (assuming it isn't full) and create new partition from
the freed up space. alternative might be to add new hard disk to the
system and change BIOS boot order specification.

IBM Unionization

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Unionization
Newsgroups: alt.folklore.computers
Date: Sat, 26 May 2007 08:47:09 -0600

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

as the bar for functionally "literate" is raised, as society and
technology becomes more complex (along with any futher decline in the US
education system) ...  it would seem that the percentage of workers that
would have to be subsidized would increase (and/or see a decline in
their standard of living).

re:
http://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#58 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#82 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#30 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#34 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#42 IBM Unionization

....

National Institute for Literacy
http://www.nifl.gov/nifl/facts/facts_overview.html

NSF Science and Engineering Indicators 2006
http://www.nsf.gov/statistics/seind06/

Chapter 1: Elementary and Secondary Education
http://www.nsf.gov/statistics/seind06/c1/c1h.htm

note that the above is mostly just gauging whether US instituations have
changed over time ... it isn't comparing them with institutions in other
industrial nations (where US currently is ranking at the bottom or near
the bottom).

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 26 May 2007 13:20:09 -0600

jmfbahciv writes:

Wonderful.  Is this going to change or will laws have to be passed
in each and every country?
<snip>

Thank you.  My instinct of paranoia was correct.

re:
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#0 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#3 John W. Backus, 82, Fortran developer, dies

aka to establish a business obligation between a trusted third party
certification authority and the "client" relying parties ... the
"client" relying parties would have to sign some sort of contract with
each the 40-50 different certification authorities that may be
represented in typical browser trusted public key respository (as
opposed to the contractual obligation that exists between trusted 3rd
party certification authorities and webservers ... when the merchant
pays the certification authority for some certification and receives a
certificate representing that certification).

this is the work-around that the Federal Gov. PKI project achieved by
having GSA sign a contract with each of the authorized certification
authorities, representing the Federal Gov as relying party
... and creating a legal obligation between the federal gov relying
parties and the certification authorities ... aka the certification
authorities sold certification to parties wishing to deal
(electronically) with the federal gov ... but w/o the GSA contract
there was no obligation that would have existed between the
certification authorities and any federal agencies relying on that
certification.

In the SSL domain name certification authority ... since it is
individual clients ... it possibly means each of the billion or so
possible clients in the world ... which may use SSL and rely on a SSL
domain name certification ... would have to sign contracts with each
of the 40-50 or so certification authorities ...  say fifty billion
contracts in aggregate (with the client paying each certification
authority some amount of money). It is no wonder that the majority of
certification authorities have disclaimers disavowing all
responsibility and liability ... since they have none (implied or
otherwise) to the entities that would be relying on the certification
(and the digital certificates).

lots of past posts about SSL digital certificates ... including their
"comfort" characteristics (i.e. they don't supply any actual business or
financial responsibility ... just the appearance of comfort).
http://www.garlic.com/~lynn/subpubkey.html#sslcert

and as noted ... there was some lobbying effort seen to get electronic
signature legislation to mandate digital signatures along with
"digital certificates" issued from authorized certification
authorities.  however, that didn't actually happen. If fact, the
contracts and business type legal people pointed out that digital
signatures don't even meet the "intent" requirement for human
signatures as having read, understood, agrees, approves, and/or
authorizes.  misc. past posts mentioning work on electronic
signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 26 May 2007 14:51:33 -0600

pechter@i4get.(none) (William Pechter) writes:

AIX had it all in '93 when I was doing it.  HP-UX and SunOS/Solaris
were getting close.

there were somewhat different AIXs ... there was the "risc" AIX.

the office products division was looking to use 801/romp in a
displaywriter follow-on product ... when that was killed ... the group
look around for something else to use it for and came up with unix
workstation.  they hired the group that had done at&t unix port for
pc/ix to do a port to romp ... and that was released as pc/rt and "AIX"
v2. RIOS was follow-on to romp for rs/6000 and AIX V2 was enhanced into
AIX V3.

separate from that ... the palo alto group had been formed to do
a port of BSD unix to mainframe ... recent reference with little
topic drift ...
http://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?

before it shipped, the effort got redirected to port to pc/rt
... eventually offering "AOS" for the pc/rt as an alternative to AIX V2.
http://www.garlic.com/~lynn/subtopic.html#801

the palo alto group had also gotten involved with UCLA and Locus ... and
eventually did a port of Locus to both the mainframe and 386 ... which
was announced as AIX/370 and AIX/PS2.

Numerous of the (mainframe) unix ports (both ibm and others) tended to
be deployed under vm370 ... the issue was that mainframe field service
organization had extensive requirements for error analysis, error
retry/recovery, and error logging/reporting. To implement a "native"
version of such in unix would have been a significantly larger total
effort than the effort doing the straight-forward port to the
mainframe. Running unix in vm370 virtual machine allowed unix to get a
free ride with regard to such requirements (since vm370 already had it
built in).

an idea of the mainframe requirements is a story i periodically tell
about having done a driver for channel extension operation around
1980.  Several yrs later ... a year after the 3090 had started
shipping, the 3090 product administrator tracted me down over a
really, really big problem. The 3090 had been design was such that
they were expecting 3-5 total 3090 channel errors to be recorded for
all installed 3090s in a years operation. After a yrs operation, they
had found that around 15 total 3090 channel errors had been recorded
(this wasn't 15 errors per channel in a yr, or 15 errors per 3090 in a
yr, this as a total of 15 errors for all installed 3090 in a yr). This
represented a really, really big problem. After some analysis, they
tracked it down to the choices I had made in the driver i had
done. The channel extension would work over a T1 telco line. If i got
a unrecoverable telco error ... i would simulate a "channel check"
operation ... which would then invoke some amount of "higher level"
retry logic ... but would also record that a "channel check" had
occured. Fiften total errors across all installed machines for a yr of
operation instead of 3-5 total errors represented a really significant
problem. So after a little investigation, I figured I could simulate
an "interface control check" (IFCC) instead of "channel check" (CC)
... and for all intents and purposes the same retry/recovery logic
would be invoked.

So I was giving a keynote at this NASA reliable computer workshop
http://www.hdcc.cs.cmu.edu/may01/index.html

and i told the story about having redone the I/O supervisor for the disk
engineering lab. They had been attempting to do development hardware
testing in operating system environment ... and found that a single
"testcell" would result in a 15min MTBF for MVS operating system.  I
undertook to rewrite the I/O infrastructure so that it would never
result in an operating system failure ... so they could do "on demand"
testing of several concurrent "test cells" w/o operating system problems
(as opposed to having to stick with their "stand alone" dedicated
testing schedules). lots of past posts about getting to play in the disk
engineering and disk product test labs
http://www.garlic.com/~lynn/subtopic.html#disk

I also described some of the stuff we had done for our high available
cluster multiprocessor product
http://www.garlic.com/~lynn/subtopic.html#hacmp

for other topic drift ... some past litany of working on ha/cmp
scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

... and finally did a short rendition of the 3090 channel check story.
Part of the story is that there has been this commercial service that
collects the error logs from customer shops ... somewhat anonymizes
the data and publishes monthly statistics.

Now, most of the major vendors were represented at the workshop ... so I
asked how many of the vendors collected all error/incident activity from
all installed machines and had detailed information about every error
from every installed machine? There was no responses. If there had been,
I was going to ask how many would have been willing to have detailed
published public reports of the information. In fact, all of the vendors
stated that divulging the information they did have would require a NDA.

misc. past posts mentioning the 3090 channel check "problem"
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2006n.html#35 The very first text editor
http://www.garlic.com/~lynn/2006y.html#43 Remote Tape drives
http://www.garlic.com/~lynn/2007f.html#53 Is computer history taught now?

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 27 May 2007 06:52:20 -0600

Steve O'Hara-Smith <steveo@eircom.net> writes:

So far only experts even attempt securing themselves properly - it
is so far from easy to do well that I really don't see any solution that
will keep the average household from being infested with keyloggers and
other delights. I think the only answer is to provide the customers with
decent one time key mechanisms with effective man-in-the middle detection
at the bank end so that they are safe even if every keystroke gets logged
or someone subverts the dataflow.

can you say "x9.59"
http://www.garlic.com/~lynn/x959.html#x959

... and AADS
http://www.garlic.com/~lynn/x959.html#aads

the security acronym "PAIN"

P ... privacy (or sometimes CAIN & confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

much of the current infrastructure requires privacy/confidentiality
where information is never divulged ... or it is subject to (static
data) replay attacks. X9.59 effectively substitutes "authentication" and
"integrity" for "privacy/confidentiality"

i.e. in the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments. the resulting x9.59 financial
standard no longer needs to "hide" transactions, account numbers, etc
... in order to preserve the integrity of the infrastructure.

this is somewhat discussed in the naked transaction/payment metaphor,
i.e. security/protection is exceedingly difficult attempting to protect
naked transactions. the other way of viewing it is that x9.59 "armors"
each, individual transaction
http://www.garlic.com/~lynn/subintegrity.html#payments

and then individuals are no longer dependent that every business process
along the processing path have absolutely perfect security (as
countermeasure to fraud).

the other part in the mid-90s was that there were some claims that the
complement to high-security was hardware tokens ... but the
state-of-the-art at the time was that the really secure hardware tokens
were too expensive for everyday operations. so we semi-facetiously said
that we would take a $500 mil-spec part, aggresively cost reduce it by
2-3 orders of magnitude while improving the security and integrity.

from 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

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

supposedly the only way that an institution could depend on a something
you have hardware token was if the institution controlled and directly
supplied each individual their hardware token. if such a "institutional
centric" paradigm was going to catch on ... an individual could
eventually have hundreds of hardware tokens ... in place of each key,
card, and/or password they currently have to deal with. the other part
of aads (besides aggresively cost reduction of 2-3 orders of magnitude
of individual, highly secure tokens) ... was to create an effective
mechanism that would allow for a transition from an "institutional
centric" paradigm to a person-centric paradigm. Instead of every
institution issuing their own token to individuals ... individuals would
be allowed to register their token with every institution (and the
infrastructure would be in place that the institutions would be able to
"trust" a person-centric registered token).

The overall infrastructure cost reduction then is 2-3 orders of
magnitude reduction in cost of each individual secure token and 2-3
orders of magnitude reduction in the number of secure tokens that an
each individual would have to carry (for an overall 4-6 orders of
magnitude total infrastructure cost reduction for a secure token
oriented environment).

misc. past posts mentioning work on being able to transition to
person-centric operation (with highly secure tokens):
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
http://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
http://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 27 May 2007 08:17:56 -0600

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

in the early 90s this somewhat showed up as x.509 identity digital
certificates. however, they tended to be grossly overloaded with
personal information and by the mid-90s most institutions began to
realize that this represented an enormous privacy and liability
problem ... and transitioned to what they called relying-party-only
digital certificates ... lots of past post discussing the "RPO"
digital certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

re:
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies

in the heat of the early 90s and x.509 identity digital certificates
... before the spreading realization of the enormous privacy and
liabiilty problems ... there were certification authority business
cases being floated that the industry would be a $20B/annum operation
... certifying and issuing renewable identity digital certificates for
every person at $100/annum.

initially there was some conjecture that this cost would be
underwritten by the financial industry. however (besides the
realization regarding the enormous privacy and liability issues), the
financial institutions realized that they already had the information
regarding their clients ... why then would the financial institutions
want to contribute $20B/annum to a certification authority industry
... for certification of information that the financial institutions
already possessed?

this possibly then was some of the motivation behind the lobbying
efforts in the electronic signature legislative activity
... attempting to get legislation effectively mandating individuals to
have identity digital certificates from officially sanctioned
certification authorities ... recent reference:
http://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies

misc. past posts discussing the $20B/annum business case scenario for
the certification authority industry
http://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
http://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
http://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?

in this period, one such example was a proposal to a large financial
institution by a certification authority ... where the financial
institution would purchase and register public key hardware tokens for
each of their accounts. then the financial institution would transmit
to the certification authority, the institution's master account file
(containing all the pertinent account information as well as the
registered public key). the certification authority then would fiddle
the bits in each account record ... creating a digitally signed
digital certificates (representing each account record). For each such
"certified" account record, the certification authority would charge
the financial institution only $100/account. the master account file
had tens of millions of records ... so in return for this bit of bit
fiddling operation, the financial institution would only be charged
several billion dollars (in addition to the cost of the hardware token
they would be buying for each account).

slightly related post on person-centric paradigm
http://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 27 May 2007 08:47:49 -0600

Charlton Wilbur <cwilbur@chromatico.net> writes:

I think it happened because of commodity computing.  All of the major
computer companies did research projects in-house, and they all ate
the costs in-house.  This meant that it was reflected in the prices of
their computers: the cost of every PDP-11 and VAX subsidized the
research and development work that was going on in the company.

But when Compaq cloned the IBM PC and made personal computers a
commodity, suddenly the manufacturer that did no in-house research and
development could charge less.  Customers voted with their pocketbooks
for the thing that cost less, not the thing that was better, because
in the short-term there was no apparent drawback.

this happened long before the ibm pc.

clone controllers showed up in the 60s ... in fact as an undergraduate,
I helped develope a "clone controller" out of interdata/3 and reverse
engineering the channel interface and building channel interface board.
this got written up blaming the four of us for the clone controller
business ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

supposedly the clone/compatible controller business then was the primary
motivation for the future system project in the early 70s:
http://www.garlic.com/~lynn/submain.html#futuresys

a reference about the motivation (that i've used numerous times):
http://www.ecole.org/Crisis_and_change_1995_1.htm

from above:

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.

... snip ...

I've also conjectured that the FS project distraction (and subsequent
failure) contributed to providing the opening for clone processers
(i.e. while FS was going on, development in 370 product line was being
neglected ... which help open opportunities for clone processors).

misc. recent posts
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
http://www.garlic.com/~lynn/2007f.html#26 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#53 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#57 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?
http://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation
http://www.garlic.com/~lynn/2007j.html#70 Using rexx to send an email
http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
http://www.garlic.com/~lynn/2007k.html#60 3350 failures

for a little other topic drift ... various litigation in the 60s also
led to the 23jun69 "unbundling" announcement where lots of ("free")
stuff started to be separately charged for ... services, software,
etc. However, the logic was used that "kernel" software should
continue to be "free" (bundled) since it was required for the
operation of the machine.
http://www.garlic.com/~lynn/submain.html#unbundle

the appearance of the clone processors in the mid/late 70s ... then
motivated the transition to charging for kernel software (i.e. not
only did the clone manufacturers have to do less hardware R&D ...
they could get by w/o having to do any operating system R&D for
the machines).

this was just about the time i was going to ship my "resource manager"
... and it got tagged to be the guinea pig for charging for kernel
software. As a result ... i got to spend some amount of time with
business and legal people working out policy and practices for kernel
software charging/pricing. misc. collected posts mentioning various
operating system performance work
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 28 May 2007 08:23:31 -0600

Frank McCoy <mccoyf@millcomm.com> writes:

Because C is/was designed as an easier way to do assembly-language,
with constructs for looping, subroutines, and control where the
overhead of putting in if-structures, returning values, and saving
registers was automatically done; NOT as a real "Higher Level
Language" with all the controls preventing programmers from doing
things they want to (like PASCAL was).  The idea was to retain all the
abilities of Assembly-Language, making programming easier, without
removing the ability to shoot yourself in the foot, by reusing labels
and deliberately using multiple parts of the same buffer for different
purposes, if that's what you really wanted to do.

one of the biggest contributor to buffer overflows in C is the
convention of using null as string length termination and not having
any conventions around length operation.

360 conventions were to use string fields that provided string length
with infrastruction conventions that length field was always managed
and dealt with (implicitly in libraries and even low-level system call
and/or explicit with inline code) ... and this convention permeated
the infrastructure, assembler, pli, cobol, pascal, etc. as a result,
the frequency of buffer overflows was significantly lower in
360 environments (even involving strictly assembler) than in any of
the C language environments.

the implicit length convention in C and little or no infrastructure
convention for handling length contributed greatly to the large number
of buffer overflows compared to many other environments
(including 360 assembler).

lots of past posts discussing buffer and length related problems
permeated infrastructures implemented in C language.
http://www.garlic.com/~lynn/subintegrity.html#overflow

up through end of last century ... buffer overflows related
issues tended to account for majority of exploits. more recently, this
has dropped to around twenty percent ... not so much because the
number of buffer overflow exploits and declined but because of
the large increase in exploits involving malicious executables
arriving from the internet and phishing exploits.

when i was doing dumprx
http://www.garlic.com/~lynn/submain.html#dumprx

some recent mention:
http://www.garlic.com/~lynn/2007i.html#44 latest Principles of Operation
http://www.garlic.com/~lynn/2007j.html#26 Even worse than UNIX
http://www.garlic.com/~lynn/2007j.html#27 Even worse than UNIX
http://www.garlic.com/~lynn/2007k.html#64 Even worse than UNIX

... one of the things i did was extensive study of types of vm370 and
cms failures (all involving code completely implemented in assembler)
... in part looking for telltale signatures that i could provide
automated diagnostic aids for identifying. the incidents of buffer
overflow was almost non-existant. i asset that is primarily
because of length handling conventions that permeated the
infrastructure (lacking in conventional C language programming) and
had little or nothing to do with language used ... since the
conventions tended to permeate all the assembler code as well as the
higher level languages.

the original mainframe tcp/ip implementation was done in vs/pascal
... and i know of no buffer length exploits as part of that
implemention. Now it could be claimed that it was related to language
characteristics of pascal ... but i also claim that it was primarily
because the whole infrastructure (regardless of language
implementation) had a much more sensible length convention.

minor digression, that base tcp/ip implemention would get about
aggregate 44kbytes/sec sustained thruput using full 3090 processor.  i
had done the changes to support rfc1044 and in some testing at cray
research was getting 1mbyte/sec sustained thruput between cray and
4341-clone ... only using modest amount of the 4341 processor (around
500 times improvement in bytes transfered per instruction executed).

as before ... one of the few buffer related items is found in this
reference regarding some local mods in cp67 kernel (also done all in
assembler)
http://www.multicians.org/thvv/360-67.html

as undergraduate, one of the modifications i had done for cp67 was add
tty/ascii terminal support (to existing 1052 and 2741 support)
... which was picked up and shipped in standard product. I had done
some optimization and was using a one-byte length field. In the above
referenced story, somebody had done a local change (MIT USL) to
increase the max. TTY/ascii line length to something like 1200 bytes
(I believe it was to support some sort of tty/ascii plotter device
located at harvard) ... but hadn't change the code that was using
one-byte values for length field.

the above story is notable in that it was one of the extremely rare
buffer overflow related incidents over several decades ... in
code that was purely assembler.

for other drift ... in adding the tty/ascii support to cp67 ... i had
tried to be consistent with the existing cp67 terminal support that
provided for automatic terminal identification ... i.e.  that any
terminal could be located on any line ... and the kernel would
correctly identify and operate. this involved use of the 2702 terminal
controller "SAD" command ... that allowed dynamic association of
different line-scanners with each line/port. I thot it was pretty
nifty and thot that it could even work with a common dial-up pool for
all terminals.  That was when the local IBM hardware engineer
explained that they had taken short-cut in 2702 implementation and
while it was possible to dynamicall associate the line-scanner
... they had hard-wired oscillators for line baud rate. 1052 and 2741
could share same dial-up pool (since while they were different
line-scanners, they shared same baud rate).

this was large part of what motivated univ. to do the clone controller
project ... reverse engineering the mainframe channel interface,
building our own channel board for interdata/3. misc. past references
http://www.garlic.com/~lynn/subtopic.html#360pcm

and mentioned in recent post (about results of clones)
http://www.garlic.com/~lynn/2007l.html#10 Re: John W. Backus, 82, Fortran developer, dies

My Dream PC -- Chip-Based

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Mon, 28 May 2007 08:59:34 -0600

Greg Menke <gdmnews@toadmail.com> writes:

Generally the idea is to put the security in the key rather than the
algorithm- which makes intuitive sense; crack the algorithm and all the
keys are compromised, crack a key and all the others have to be cracked
individually.

or you put the security engineering into the algorithm ... making it
extremely unlikely to be cracked ... which then primarily leaving
attacks on individual keys (which you then have to protect with
privacy/confidentiality ... never allowing it to be divulged).

one of the issues is still the computational overhead of public/private
key algorithms and the continued dependence on "secret" key algorithms.

one of the places this shows up is things like large transit systems and
the encoding of transit passes. using a "secret" key algorihtm ... there
has to be an infrastructure wide "secret" in use at all the transit
gates and devices in the system. This creates an enormous systemic risk
... for even brute force attacks on the key. To mitigate that risk they
typically will use a system-wide "secret" key with a "one-way" algorithm
to produce an account/card/ticket specific key for the encryption of
actual data. The system "secret" key is computational changed using some
sort of account/card/ticket identification/serial number ... which is
then used as actual key for encrypting data in each transit pass.  Brute
force on the transit pass ... only recovers the transit pass specific
key ... but is nearly impossible to brute force the original system
secret key.

There is still systemic risk involving the individual transit gates
(attempts to extract the system-wide master "secret" key) ... but they
tend to be heavily armored.

This is one of the reasons in the 90s ... we put out a call with
requirement for public/private key implementation that 1) could be done
by contactless/proximity chip (draws its power thru the air when near a
reader ... and therefor has power profile limitations) and 2) could be
used in transit applications (transit gate transaction requirements
typically have elapsed time requirement on the order of 100-200
mills). some old "AADS" references, including AADS chip strawman
http://www.garlic.com/~lynn/x959.html#aads

that was in conjunction about previous semi-facetious comment about also
being able to take a $500 mil-spec part and aggresively cost reduce it
by 2-3 orders of magnitude while increasing its security.
http://www.garlic.com/~lynn/2007l.html#8 Re: John W. Backus, 82, Fortran developer, dies

aka ... AADS chip strawman was to 1) super secure, 2) dirt cheap, 3)
contactless, 4) public/private key, 5) meet transmit elapsed time
requirements

one of the alternative chip public/private approaches in the 90s was to
implement 1100-bit math operations ... in attempt to drastically reduce
the elasped time for prevailing public/private key operations. However,
this typically resulted in drastically increasing the power draw (not
practical in proximity chip operation). also because of the significant
computational intensity for the prevailing public/private key operations
... the private key was vulnerable to things like differential power
attacks. part of AADS chip strawman was to get away from all that.

for other topic drift ... the circuits for the 1100-bit operations
tended to significantly increase chip size (in addition to significantly
increasing power draw) ... which cut the number of chips per wafer
... increasing the per chip cost.

part of the AADS chip strawman aggresive cost reduction
was KISS ...  and cutting chip size where ever possible (w/o
sacrificing integrity/security). Chip manufacturing is somewhat fixed
cost per wafer ... the more chips you get per wafer ... the lower the
per chip cost (this is also behind things like the move from 8in to
12in wafers).

My Dream PC -- Chip-Based

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Mon, 28 May 2007 09:12:13 -0600

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

for other topic drift ... the circuits for the 1100-bit operations
tended to significantly increase chip size (in addition to
significantly increasing power draw) ... which cut the number of chips
per wafer ... increasing the per chip cost.

part of the AADS chip strawman aggresive cost reduction
was KISS ...  and cutting chip size where ever possible (w/o
sacrificing integrity/security). Chip manufacturing is somewhat fixed
cost per wafer ... the more chips you get per wafer ... the lower the
per chip cost (this is also behind things like the move from 8in to
12in wafers).

re:
http://www.garlic.com/~lynn/2007l.html#8 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007l.html#12 My Dream PC -- Chip-Based

minor footnote ... one of the problems we were starting to get into with
AADS chip strawman was that conventional slicing and dicing a wafer was
starting to take over half the wafer area ... this is also something
that the "RFID" chips (i.e. super small/cheap chips with target market
as inventory control and next generation UPC ... i.e.  bar-code
replacement) have had to deal with.

Superconductors and computing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Superconductors and computing
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 28 May 2007 10:14:06 -0600

jgd@cix.co.uk (John Dallman) writes:

As I remember a conversation quite a few years ago, some Josephson
junction machines were designed, but not built. There was a problem in
that once they'd been cooled down, warming them up again, for
maintenance or transport, didn't appear to be possible without damaging
them.

from some where long ago and far away


To: wheeler
Date: 10/05/81 14:11:45

Hi Lynn !

I don't know if you remember me. You helped me find a place to live
this summer at Yorktown which worked out very well. Well, after that
example of successful networking I thought I would give it another try

I've just got back from my stint at Yorktown and am trying to get back
into the swing of things here. After spending all summer playing with
Josephson junction devices, and seeing the state of that project, I've
decided that software is where it's at for me ! I will be finishing off
my Masters in EE/CS at Stanford shortly, and am continuing towards the
Phd. I'm very interested in combining a work project and a dissertation
topic.  Topics within A.I., graphics, networking, interactive education,
distributed processing are all very interesting to me. What I really
need is a supportive environment for learning, and hopefully producing
truly creative software products. My programming background so far
includes experience to varying degrees in: PLS, 370 assembler, VM
(REX,EXEC2,etc) APL, Pascal, and LISP.

Finally comes the question, Do you know of anyplace in IBM (preferably
Palo Alto, or San Jose Research) for someone like me ? Put the
question another way, Is creative software being produced, or
supported anywhere locally within IBM ? If so, who should I talk to ?

Thanks much !

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

the way i remember it, one of the last things that eric did as head of
east fishkill was shutdown josephson junction effort.

minor reference here
http://www-03.ibm.com/ibm/history/exhibits/builders/builders_bloch.html

and for other archeological drift: Contact Info for the Stretch
Reunion, Sept. 28-29, 2002
http://users.bestweb.net/~collier/sh/arch/contact.html

of course, eric shows up later as head of NSF for much of the '80s
... minor old email references here working with eric on NSFNET and
fighting/loosing internal battles
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

i.e. some corporate members stepped in and started canceling our
outside meetings ... and then tried to get "SNA" substituted (for
tcp/ip) in nsfnet backbone ... example from (another) old email
http://www.garlic.com/~lynn/2006w.html#email870109
in this post
http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

Eric writting letters copying ceo didn't even help (actually made the
situation worse). We did get a letter from NSFNET audit of what we had
already deployed (internally) that what we had running was at least
five yrs ahead of all (NSFNET backbone) bid submissions to build
something new ... aka while tcp/ip is the technology basis for the
modern internet, NSFNET backbone was the operational basis for the
modern internet.

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 28 May 2007 12:19:12 -0600

Charlton Wilbur <cwilbur@chromatico.net> writes:

Will be?  The global markets and financial infrastructures are
almost completely dependent on computers *now*.

one of the hot new things is straight through processing and multi-core.

a lot of the infrastructures have been built on serial batch (frequently
cobol) processing. in the 80s, some of this started being front-end with
online stuff for transaction origination ... but they typically
continued to feed into (overnight) serial batch process to actually
finalize/settle the operation.

in the 90s, one of the big (bottleneck) issues for these infrastructures
became the overnight batch window ... globalization contributed to
both increasing the amount of workload (that eventually had to be
funneled thru the overnight batch window) and the decreasing size of the
batch window (i.e. downtime when there was little or no other activity
going on).

for several yrs an issue is how to leverage various kinds of parallelism
to implement (real-time) straight through processing. Foreys into this a
decade ago found that they were running into scale-up problems ... aka
they had "toy" demos of (real-time) straight through processing ... but
when they went to try real deployments, they were finding that the
"parallelization" technologies were resulting in 100-fold overhead
increase (compared to the legacy serial batch implementations) ... which
adversely affected any deployment (to show actual capacity increase with
straight through processing methodologies ... you needed something like
200-300 times the computing processing that the overnight batch windows
were currently using. The intial realization was real-time was much less
efficient than serial batch ... so you needed a lot more resources, to
get a lot more resources required moving to parallel ... however (at
least standard COTS) parallelization technology also soaked up huge
amounts of resources (resulting in the 100-fold increase). There were a
whole litney of major straight through projects in the 90s that went
down in flames over the issue.

this issue of parallelization is again coming to the forefront with all
the multi-core stuff ... as well as blade stuff. in the case
of the blade stuff ... it is sort of natural evolution of the ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
scaleup work we had been doing
http://www.garlic.com/~lynn/lhwemail.html#medusa

the original cluster scaleup found big niche in the numerical intensive
market segment. blades were somewhat motivated by physical packaging and
getting more and more (commodity) computing into smaller and smaller
footprint. some of the initial foreys into trying to move all that
technology into more commercial sector has been things like trading
houses using vast array of blades in support of (near) real-time
trading analytics.

more recently some of the blade movement into commercial has been in
combination with virtualization and server/application consolidation ...
getting huge numbers of corporate servers into more manageable (and cost
effective) configurations.

however, lurking in the background continues to be the issue about
(re)tackling the straight through processing (and real-time settlement)
holy grails ... possibly with contribution of combining multi-core and
blades (i.e. combining both "tightly" coupled multiprocessing and
massive "loosely" coupled multiprocessing). although old posts
mentioning shared-memory/symmetric/tightly-coupled multiprocessing,
building smp kernels and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

however, one of the constant refrains over the post couple yrs (around
the movements to multi-core) is needing a qualitative improvement
(and/or paradigm change) in application parallelization technology.

misc. past posts mentioning various kinds of straight through
processing efforts:
http://www.garlic.com/~lynn/aadsm17.htm#12 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#20 ID "theft" -- so what?
http://www.garlic.com/~lynn/2001b.html#27 HELP
http://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#14 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#17 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2006c.html#45 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006s.html#40 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2007b.html#26 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007e.html#10 A way to speed up level 1 caches

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 28 May 2007 12:43:02 -0600

Charlton Wilbur <cwilbur@chromatico.net> writes:

Will be?  The global markets and financial infrastructures are
almost completely dependent on computers *now*.

re:
http://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies

for another perspective on the subject ... X9
http://www.x9.org/

is the US financial industry standards body (and chair of ISO
international finanical standards).

X9 committees include both X9A, for retail financial business standards
and X9F for security and cryptographic standards.

For quite awhile nist
http://www.nist.gov/

had been use to writting/developing federal cryptographic standards
from scratch.  sort of one of the x9f milestones was when nist changed
its policy and directly cited X9F work for federal standards.

I've periodically mentioned work on X9.59 financial industry standard
http://www.garlic.com/~lynn/x959.html#x959

in the X9A10 working group. a couple somewhat related recent posts
http://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#12 My Dream PC -- Chip-based
http://www.garlic.com/~lynn/2007l.html#12 My Dream PC -- Chip-based

now, most of X9.59 standardization activity involved a lot of
cryptographic oriented work ... and previously the standard activity
would have been done in one of the X9F (cryptographic) working
groups. However, the decision to instead put the work in a X9A (retail
business) working group was in part motivated by wanting to see the
technology aligned with the business processes. Previously, it had
been possible for X9F to preduce a technology standards that might
have little or no alignment with financial industry business
processes.

One slightly related hot button was when we kept pointing out that
X9.59 transactions would be secured with digital signatures ... w/o
requiring any digital certificates ... some certificate-less related
posts
http://www.garlic.com/~lynn/subpubkey.html#certless

and mentioning that some of the payment transaction specifications
being done elsewhere involving appending digital certificates
represented was causing a factor of 100 times increase in the size of
a typical payment transactions ... misc. past posts mentioning the
enormous bloat that (obsolete, redundant and superfluous) digital
certificates would cause in payload size (as well in computational
requirements for payload processing)
http://www.garlic.com/~lynn/subpubkey.html#bloat

this possibly contributed to new work item in X9F for standards work
on "compressed" digital certificates ... potentially getting the
enormous payload bloat down from 100 times to possibly only 5-10 times
(appending obsolete, useless, redundant and superfluous digital
certificate)

one of the compression techniques being looked at was eliminating all
digital certificate fields that were common/identical across all of
the institutions digital certificates. I took it a step further
... and pointed out that all fields that were already in the
possession of the institution (and would be normally accessed in an
account record as part of standard processing) could also be
eliminated from digital certificates ... allowing the digital
certificates to be compressed to zero bytes (i.e. it was trivial to
show that all fields that might be in a digital certificate were
already in the possession of the institutions). This approach was an
alternative to having certificate-less digital signature operations
... instead, zero byte digital certificates could be mandated for every
transaction.

for other drift ... some other recent posts mentioning digital certificates
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#63 public key password authentication
http://www.garlic.com/~lynn/2007i.html#73 public key password authentication
http://www.garlic.com/~lynn/2007j.html#67 open source voting
http://www.garlic.com/~lynn/2007k.html#32 SSL Security
http://www.garlic.com/~lynn/2007k.html#55 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#9 Re: John W. Backus, 82, Fortran developer, dies

Linux: The Completely Fair Scheduler

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux: The Completely Fair Scheduler
Newsgroups: alt.folklore.computers
Date: Mon, 28 May 2007 19:34:02 -0600

Walter Bushell <proto@oanix.com> writes:

I remember being put of the spot by being asked whether DMA took over
the machine or let the system[1] run. I, of course, answered "both". How
can it be "both" inquired my boss laughing. Then I had to explain cycle
stealing. Later I figured that the max DMA rate would slow the machine
by 20%.

one of the early bugs we had doing the clone controller
http://www.garlic.com/~lynn/subtopic.html#360pcm

was in the mainframe channel board attachment to 360/67 channel ...
recent reference
http://www.garlic.com/~lynn/2007l.html#10 John W. Backus, 82, Fortran developer, dies

one of the first "bugs" was 360/67 "red lighted" (i.e. machine check
and stopped). the problem was that 360/67 had high-speed interval
timer ...  which required updating location 80 in main memory on every
timer tic.  the timer would attempt to obtain the memory bus to update
location 80 ... and if the timer "tic'ed" again while there was
already a pending update ... the machine would "red light" and
stop. the problem was that our clone channel adatper board wasn't
releasing the interface frequently enuf (in order to allow the timer
to update location 80).  misc. past posts mentioning early hardware
bug in clone controller project:
http://www.garlic.com/~lynn/2003.html#25 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2005o.html#36 Penn Central RR computer system failure?
http://www.garlic.com/~lynn/2006c.html#21 Military Time?
http://www.garlic.com/~lynn/2006g.html#18 TOD Clock the same as the BIOS clock in PCs?

standard location 80 timer was 32bits ... lower-end 360s would tic the
8th bit every 1/300th second. high speed timer option would tic 256
times more frequently (about 13microseconds).

other (unrelated) posts in this thread
http://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
http://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
http://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
http://www.garlic.com/~lynn/2007i.html#46 Linux: The Completely Fair Scheduler
http://www.garlic.com/~lynn/2007j.html#76 Linux: The Completely Fair Scheduler

Non-Standard Mainframe Language?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Non-Standard Mainframe Language?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 28 May 2007 20:34:30 -0600

gilmap@ibm-main.lst (Paul Gilmartin) writes:

Much of this is due to the reliance on null-terminated strings, which
are not peculiar to C, but are rooted in the UNIX continuum between
applications programming and systems programming.

i've actually had this discussion with some of the people involved,
null allowed for one byte overhead for arbitrary lengths ... somewhat
the y2k phenomena ... as opposed to the two byte explicit length
overhead (for up to 64k).

x-over post on the subject from today in another fora
http://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran developer, dies

lots of posts on the subject of exploits/failures related to the
characteristic
http://www.garlic.com/~lynn/subintegrity.html#overflow

i had been monitoring some of the statistics thru the 90s ... but more
recently there were much fewer ... so i had to do some analysis myself
... looking at some of the exploit databases. part of the problem
(that I complained about) was that many of the descriptions were
somewhat freeform and could be ambiguous ... which i complained about
a number of times. there were some more recent announcements that they
would be attempting to better classify/categorize exploits.

old posts with some attempts at classification/categorization based
on analysis of some of the exploit databases
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
http://www.garlic.com/~lynn/2004j.html#58 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005b.html#43 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#32 [Lit.] Buffer overruns

and this one mentions an article in early 2005 quoting a NIST
study that came up with similar statistics that I had come up
with nearly a year earlier:
http://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns

note part of the mentioned efforts was in support of my merged
security taxonomy and glossary ... some notes here:
http://www.garlic.com/~lynn/index.html#glosnote

past posts in this thread:
http://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#73 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007k.html#74 Non-Standard Mainframe Language?

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 29 May 2007 00:16:52 -0600

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

however, one of the constant refrains over the post couple yrs (around
the movements to multi-core) is needing a qualitative improvement
(and/or paradigm change) in application parallelization technology.

re:
http://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies

recent item along these lines:

Is Parallel Programming Just Too Hard?
http://developers.slashdot.org/developers/07/05/29/0058246.shtml

Intel: Software needs to heed Moore's Law
http://news.com.com/Intel+Software+needs+to+heed++Moores+Law/2100-1012_3-6186765.html

recent posts mentioning the multi-core & parallel programming paradigm issue:
http://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2007g.html#3 University rank of Computer Architecture
http://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
http://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran developer, dies

and lots of past posts mentioning cluster/loosely-coupled (parallel)
support
http://www.garlic.com/~lynn/subtopic.html#hacmp

and somewhat related posts about distributed lock manager work in support
of the above:
http://www.garlic.com/~lynn/2007i.html#50 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#61 John W. Backus, 82, Fortran developer, dies

misc. posts mentioning my wife got con'ed to doing stint in POK
in charge of loosed-coupled multiprocessor architecture
http://www.garlic.com/~lynn/submain.html#shareddata

some old email related to cluster scale-up work
http://www.garlic.com/~lynn/lhwemail.html#medusa

misc. pasts mentioning (parallel) tightly-coupled multiprocessor
work
http://www.garlic.com/~lynn/subtopic.html#smp

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 29 May 2007 08:52:17 -0600

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

a lot of the infrastructures have been built on serial batch (frequently
cobol) processing. in the 80s, some of this started being front-end with
online stuff for transaction origination ... but they typically
continued to feed into (overnight) serial batch process to actually
finalize/settle the operation.

re:
http://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#16 John W. Backus, 82, Fortran developer, dies

some cross-over from this "cobol" thread
http://www.garlic.com/~lynn/2007k.html#66 The top 10 dead (or dying) computer skills
http://www.garlic.com/~lynn/2007k.html#69 The top 10 dead (or dying) computer skills

there was follow-up mention of "cobol":

You can't kill a skill; How even a Cobol expert can find career gold
http://www.itbusiness.ca/it/client/en/home/News.asp?id=43656

and for even more drift ... a recent reference to doing some performance
tuning on one such large cobol (450k lines) application that ran on over
40 mainframe "CECs" (that were something in excess of $30m/per) ... and
was able to get something like 15percent improvement:
http://www.garlic.com/~lynn/2007f.html#47 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#48 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#51 Is computer history taught now?

Non-Standard Mainframe Language?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Non-Standard Mainframe Language?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 29 May 2007 11:00:07 -0600

Dan Espen <daneNO@MORE.mk.SPAMtelcordia.com> writes:

No, in the sense that C was pretty close to the assembler for
the machine UNIX was first developed on.

It would have been interesting if K&R went on to implement UNIX
on a 360 type machine.  I assume they would have extended the
C language and library functions to better exploit the hardware.

re:
http://www.garlic.com/~lynn/2007l.html#18 Non-Standard Mainframe Language?

when i was undergraudate, i had added tty/ascii terminal support to cp67
... in the process of doing that ... came up with some difficiencies in
the 2702 terminal controller ... that somewhat prompted project to build
our own clone controller out of interdata/3 ... which had somewhat
360-like instruction set. recent post making reference:
http://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran developer, dies

there was some article blaming us (at least in part) for the clone
controller business.  lots of past posts mentioning clone controllers
http://www.garlic.com/~lynn/subtopic.html#360pcm

all the references I've seen regarding redoing C & UNIX for portability
make mention of (later) interdata machines (again 360-like)

The First Unix Port
http://www.usenix.org/publications/library/proceedings/usenix98/invited_talks/miller.ps
Version 6 Unix - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Version_6_Unix
Interdata_v6
http://minnie.tuhs.org/UnixTree/Interdata_v6/
Anecdotes
http://doi.ieeecomputersociety.org/10.1109/MAHC.1989.10025
The Daemon, the GNU and the Penguin - Chapter 2 and 3
http://www.icims.csl.uiuc.edu/~lheal/doc/dgp/chapter02_03.html

of course these machines were quite a bit after interdata/3

Interdata 7/32 and 8/32
http://en.wikipedia.org/wiki/Interdata_7/32

in the above ... references to perkin-elmer having bought interdata and
quite a bit of success in "defense and aerospace" industries. people
i've talked to since, have said that a lot of the sales involved
attaching to ibm mainframe ... and the channel attach board didn't
appear to have been redesigned since our original (still wire-wrap).

Interdata Simulator Configuration
http://simh.trailing-edge.com/interdata.html

from above:

Interdata was founded in the mid 1960's. It produced a family of 16b
minicomputers loosely modeled on the IBM 360 architecture.
Microprogramming allowed a steady increase in the functionality of
successive models.

    * Interdata 3
    * Interdata 4 (autoload, floating point)
    * Interdata 5 (list processing, microcoded automatic I/O channel)
    * Interdata 70, 74, 80
    * Interdata 6/16, 7/16
    * Interdata 8/16, 8/16e (double precision floating point, extended memory)

In the early 1970's, Interdata was purchased by Perkin-Elmer. In 1974,
it introduced one of the first 32b minicomputers, the 7/32. Several
generations of 32b systems followed:

    * Interdata 7/32
    * Interdata 8/32
    * Perkin-Elmer 3205, 3210, 3220
    * Perkin-Elmer 3250

Interdata was spun out of Perkin-Elmer as Concurrent Computer
Corporation.

U.S. Cedes Top Spot in Global IT Competitiveness

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: U.S. Cedes Top Spot in Global IT Competitiveness
Newsgroups: alt.folklore.computers
Date: Wed, 30 May 2007 08:38:12 -0600

new item in ongoing thread:

Asia leads in IT innovation
http://www.zdnetindia.com/zdnetnew2007/index.php?action=article&prodid=6725

from above:

Entitled "IT Investments, performance and priorities in Southeast Asia's
major economies", the survey polled 48 CIOs and CTOs from Malaysia (33
percent of respondents), Singapore (37 percent) and Indonesia (30
percent). The study is part of Accenture's global high-performance IT
research covering 500 CIOs from the world's largest and public sector
organizations in 22 countries.

... snip ...

recent posts in thread::
http://www.garlic.com/~lynn/2007g.html#6 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#35 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#68 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007i.html#13 U.S. Cedes Top Spot in Global IT Competitiveness

recent posts in related threads:
http://www.garlic.com/~lynn/2007h.html#42 Experts: Education key to U.S. competitiveness
http://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#30 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#34 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#42 IBM Unionization

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 30 May 2007 08:46:43 -0600

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

the original cluster scaleup found big niche in the numerical intensive
market segment. blades were somewhat motivated by physical packaging and
getting more and more (commodity) computing into smaller and smaller
footprint. some of the initial foreys into trying to move all that
technology into more commercial sector has been things like trading
houses using vast array of blades in support of (near) real-time
trading analytics.

more recently some of the blade movement into commercial has been in
combination with virtualization and server/application consolidation ...
getting huge numbers of corporate servers into more manageable (and cost
effective) configurations.

re:
http://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies

Getting much, much more per x86 rack
http://weblog.infoworld.com/yager/archives/2007/05/getting_much_mu.html

from above:

We squeeze 40 servers into a full-height rack. For isolation and
fine-grained load balancing of a .Net e-commerce solution, we want to
split our rack into as many Windows Server virtual machines as
possible. Our response time tests led us to allocate three virtual
servers per rack unit, yielding 120 VMs per rack.

... snip ...

note that medusa (from 91) ... was squeezing 32 "servers" into
full-height rack (todays blades are able to get even higher
density)
http://www.garlic.com/~lynn/lhwemail.html#medusa

of course, virtual machines is the latest, new 40+yr old technology.

Is Parallel Programming Just Too Hard?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Parallel Programming Just Too Hard?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 May 2007 09:40:55 -0600

howard@ibm-main.lst (Howard Brazee) writes:

Depending on one's definition of parallel programming, we have been
doing to various degrees since before they started off-loading the
paper-tape reading to the paper-tape reader.    Video cards on PCs are
powerful computers that work in parallel with the program's main
logic.     Our operating systems have allowed us to run payroll and
accounts payable at the same time, and central databases have expanded
on this ability.

lots of comments about this in the past couple yrs is that technology in
support of parallel programming has not really changed in at least the
past 20yrs ... as a result, the actual use has been limited to very
specialized implementations.

there has been lots of stuff in multiprogramming and multithreading in
the same processor complex (single processor and/or shared-memory
multiprocessor).

multiprogramming was managing lots of independent & different tasks
on the same processor complex.

multithreading was program managing different tasks.

application implementation of multithreading isn't necessarily very
pervasive. some number of DBMS implementation have used things like
transaction model ... to provide "independent" operations ... that they
multithread. In this sense, DBMS kernels are somewhat more like
operating system kernels ... highly specialized ... and not a lot of
end-users implementing their own DBMS kernels.

in a lot of multiprocessor kernel support ... a "global" kernel lock was
used ... which only allowed a single thread to be executing in the
kernel at a time. it was somewhat painful experience for a lot of kernel
implementations to make the transition from single thread (at a time)
executing in a multiprocessor kernel to multiple concurrent threads
executing in same parts of the kernel.

long ago and far away, this was one of the battles getting the
compare&swap instruction into 370 architecture. test&set had been around
in the 60s and was used fro 360/65 multiprocessor support with global
kernel spin-locks (set the lock and everybody else spins, untill the
lock is cleared).

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

Charlie had been doing a lot of work in fine-grain lock for the cp67
kernel and invented the compare&swap instruction (mnemonic chosen
because "CAS" are charlie's initials). misc. past posts mentioning
SMPs and/or compare&swap
http://www.garlic.com/~lynn/subtopic.html#smp

somewhat implicit in a lot of compare&swap uses is that there can be
concurrent threads executing in the same instruction sequences
simultaneously. the inital forey into POK attempting to get compare&swap
justified was unsuccesful, in large part because the favorite son
operating system felt that test&set was just fine for multiprocessor
support (the 360/65 smp global spin lock paradigm). the challenge was to
create justification for compare&swap instruction that was applicable to
single processor deployment. Thus was born the programming notes that
can be found in principles of operation describing how the "atomic"
characteristics of comapre&swap can be leveraged in single processor
environment for multithreaded applications (like DBMS) ... these aren't
necessarily concurrent multithreads ... but multiple threads that might
be interrupted and so atomic operations can be applied to both
simultaneous concurrent multithread operation as well as possibly
non-simultaneous (but interrruptable) multithreaded operation.

the advances in concurrent, parallel technology into
loosely-coupled/cluster deployments is even more limited than the
proliferation in tightly-coupled environments.

we had done a scallable distributed lock manager in support of
our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

and the "medusa" cluster-in-a-rack activity ... old email
http://www.garlic.com/~lynn/lhwemail.html#medusa

and somewhat referenced in these postings about old meeting
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/96.html#15

... but again ... it tended to be directly used by a very limited amount
of specailized code ... there wasn't a huge number of different
applications directly implementing semantics of highly parallel
operation (for either tightly-coupled or loosely-coupled
configurations).

a couple recent posts in another thread/fora on the subject
http://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#19 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#23 John W. Backus, 82, Fortran developer, dies

Computer tube production years

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer tube production years
Newsgroups: alt.folklore.computers
Date: Wed, 30 May 2007 10:29:36 -0600

hancock4 writes:

I knew of a hospital that used a 1401 under those terms to the end of
the computer's useful physical life.  I'd guess a 1401 had a physical
service lifespan of about eight years, after which circuit failures
would become a problem in providing dependable service.  (In other
words, the machine would still run, but break down too often to be
reliable.)  Would anyone else be familiar with hardware service lives
of that generation?

or in that period ... it was taking 7-8 yrs to come out with a new
product ... somewhat like the domestic automobile industry up until
almost the early 90s. to somewhat compensate some organizations would
run two parallel efforts ... offset by 3-4 yrs ... and they could do
comestic changes on an annual basis.

Is Parallel Programming Just Too Hard?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Parallel Programming Just Too Hard?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 30 May 2007 10:41:16 -0600

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

long ago and far away, this was one of the battles getting the
compare&swap instruction into 370 architecture. test&set had been around
in the 60s and was used fro 360/65 multiprocessor support with global
kernel spin-locks (set the lock and everybody else spins, untill the
lock is cleared).
...
somewhat implicit in a lot of compare&swap uses is that there can be
concurrent threads executing in the same instruction sequences
simultaneously. the inital forey into POK attempting to get compare&swap
justified was unsuccesful, in large part because the favorite son
operating system felt that test&set was just fine for multiprocessor
support (the 360/65 smp global spin lock paradigm). the challenge was to
create justification for compare&swap instruction that was applicable to
single processor deployment. Thus was born the programming notes that
can be found in principles of operation describing how the "atomic"
characteristics of comapre&swap can be leveraged in single processor
environment for multithreaded applications (like DBMS) ... these aren't
necessarily concurrent multithreads ... but multiple threads that might
be interrupted and so atomic operations can be applied to both
simultaneous concurrent multithread operation as well as possibly
non-simultaneous (but interrruptable) multithreaded operation.

re:
http://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?

misc. past posts mentioning smp and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

in the mid-70s i was working on a 5-way SMP implementation it involved
one of the lower-end 370 processor designs ... and was moving lots of
features into microcode. for one reason or another that project got
killed, misc. past posts discussing the effort
http://www.garlic.com/~lynn/submain.html#bounce

shortly after that got killed, there was another project started for
16-way smp involving higher-end processors. we even co-opted the spare
time from some of the processor engineers furiously attempting to
complete the 3033. in general, most people that looked at it thought it
was a really great idea ... until it came to the attention of the head
of POK that it would possible be decades before the POK favorite son
operating system would be able to support the machine. At which time,
the 3033 engineers were instructed to get their noses back to the
grindstone and some people were invited to never show up in POK again.

misc. past references:
http://www.garlic.com/~lynn/95.html#5 Who started RISC? (was: 64 bit Linux?)
http://www.garlic.com/~lynn/95.html#6 801
http://www.garlic.com/~lynn/95.html#11 801 & power/pc
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2002i.html#82 HONE
http://www.garlic.com/~lynn/2003.html#4 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#26 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004j.html#45 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
http://www.garlic.com/~lynn/2005k.html#45 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005m.html#48 Code density and performance?
http://www.garlic.com/~lynn/2005p.html#39 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006l.html#30 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006n.html#37 History: How did Forth get its stacks?
http://www.garlic.com/~lynn/2006r.html#22 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?
http://www.garlic.com/~lynn/2007g.html#57 IBM to the PCM market(the sky is falling!!!the sky is falling!!)

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 30 May 2007 12:52:07 -0600

kkt <kkt@zipcon.net> writes:

_Starting_ to convert was mostly in the 1960s and 1970s, the initial
phase being building an online catalog only of the newly-cataloged
material.  By the 1980s and 90s many libraries were finished with the
two-systems phase (card and online) and had gone to online only.

university library got an ONR grant to do online catelogue ... and
project was selected to be one of the original CICS betatest sites (late
60s, CICS had been originally developed at a customer site ... and this
was turning it into a standard product offering). As an undergraduate I
got roped into doing some of the early CICS debugging ... using BDAM
files under os/360 ... some amount of old posts about CICS betatest
and/or BDAM files
http://www.garlic.com/~lynn/submain.html#bdam

in the 90s we spent some time talking to the national library of
medicine ... which had online cateloge providing world-wide access.  The
two original developers were still there and were still running BDAM
implementation that they had first done about the same time I was doing
stuff for the university library.

misc. past posts mentioning NLM (for one reason or another):
http://www.garlic.com/~lynn/94.html#26 Misc. more on bidirectional links
http://www.garlic.com/~lynn/2001c.html#67 What ever happened to WAIS?
http://www.garlic.com/~lynn/2001i.html#27 History of Microsoft Word (and wordprocessing in general)
http://www.garlic.com/~lynn/2001j.html#1 Off-topic everywhere [was: Re: thee and thou
http://www.garlic.com/~lynn/2001m.html#51 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2002g.html#3 Why are Mainframe Computers really still in use at all?
http://www.garlic.com/~lynn/2002h.html#0 Search for Joseph A. Fisher VLSI Publication (1981)
http://www.garlic.com/~lynn/2002l.html#53 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002l.html#68 10 choices that were critical to the Net's success
http://www.garlic.com/~lynn/2002o.html#45 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2002o.html#50 XML, AI, Cyc, psych, and literature
http://www.garlic.com/~lynn/2004e.html#53 c.d.theory glossary (repost)
http://www.garlic.com/~lynn/2004f.html#0 c.d.theory glossary (repost)
http://www.garlic.com/~lynn/2004f.html#1 c.d.theory glossary (repost)
http://www.garlic.com/~lynn/2004l.html#52 Specifying all biz rules in relational data
http://www.garlic.com/~lynn/2004m.html#61 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#47 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#67 Relational vs network vs hierarchic databases
http://www.garlic.com/~lynn/2004p.html#0 Relational vs network vs hierarchic databases
http://www.garlic.com/~lynn/2005.html#23 Network databases
http://www.garlic.com/~lynn/2005c.html#41 Oldest active information system
http://www.garlic.com/~lynn/2005d.html#57 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005j.html#45 Where should the type information be?
http://www.garlic.com/~lynn/2005j.html#47 Where should the type information be?
http://www.garlic.com/~lynn/2006e.html#34 CJ Date on Missing Information
http://www.garlic.com/~lynn/2006l.html#31 Google Architecture

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 30 May 2007 13:16:09 -0600

"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:

Still, some places - like the UBC library - did use cards back when
I was there (around 1970).  The card in the pocket in the book was
an 80-column card punched with the book's title, etc. - with lots
of "#" symbols providing space fill.  When you checked out a book,
the librarian would feed the card through an IBM terminal which
contained a low-speed card reader.  Your student ID card - which
was a very truncated 80-column card punched with your number -
also went into the terminal.

lots of places used punch cards for all sorts of inventory and
control processes. anybody remember getting bills/invoices that
included 80-column punch card ... and all the notices about
"DON'T SPINDLE, BEND/FOLD, OR MUTILATE" ?????

John W. Backus, 82, Fortran developer, dies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 30 May 2007 14:27:27 -0600

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

"DO NOT BEND, FOLD, OR MUTILATE" ?????

re:
http://www.garlic.com/~lynn/2007l.html#28 John W. Backus, 82, Fortran developer, dies

or "fold, spindle or mutilate" ... quick use of search engine
http://www.lileks.com/institute/compupromo/4.html

tab browsing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: tab browsing
Newsgroups: alt.folklore.computers
Date: Wed, 30 May 2007 16:18:55 -0600

i frequently do a lot of tab browsing ... not uncommon to have 50-150
tabs open ... recent test with firefox 3, I opened over 900 tabs (at one
time). i also do some stuff bookmarking collections of tabs in tab
folder ... and then copying them out of bookmark file into other places.
firefox 3 just recently moved their bookmark file to sqlite ...  which
presented a little of a issue

however, with little help with shell and command line sqlite processor
... the following sql statement gets me all the bookmark URLs from the
most recent tab folder (all in one line):

 select moz_bookmarks.title,url from moz_bookmarks join moz_places on
  moz_bookmarks.fk = moz_places.id where moz_bookmarks.parent =
  (select max(id) from moz_bookmarks where parent = 2);

i.e. "parent = 2"