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

Refed: **, - **, - **, - **, - **, - **, - **, - **
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:
https://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 successful 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
https://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
https://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
https://www.garlic.com/~lynn/subpubkey.html#sslcert

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

The top 10 dead (or dying) computer skills

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

John W. Backus, 82, Fortran developer, dies

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


re:
https://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#0 John W. Backus, 82, Fortran developer, dies
https://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.
https://www.garlic.com/~lynn/x959.html#aads

other posts having been brought in to help word-smith electronic signature legislation.
https://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:
https://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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
https://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#58 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#82 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#30 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#34 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#42 IBM Unionization

....

National Institute for Literacy
https://web.archive.org/web/20100413134230/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

Refed: **, - **, - **, - **
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:
https://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#0 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies
https://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).
https://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
https://www.garlic.com/~lynn/subpubkey.html#signature

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sat, 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 ...
https://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.
https://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 occurred. 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
https://web.archive.org/web/20011004023230/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
https://www.garlic.com/~lynn/subtopic.html#disk

I also described some of the stuff we had done for our High Availability Cluster Multi-Processing product
https://www.garlic.com/~lynn/subtopic.html#hacmp

for other topic drift ... some past litany of working on ha/cmp scale-up
https://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"
https://www.garlic.com/~lynn/2005e.html#13 Device and channel
https://www.garlic.com/~lynn/2006n.html#35 The very first text editor
https://www.garlic.com/~lynn/2006y.html#43 Remote Tape drives
https://www.garlic.com/~lynn/2007f.html#53 Is computer history taught now?

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 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"
https://www.garlic.com/~lynn/x959.html#x959

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

the security acronym "PAIN"

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
https://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
https://www.garlic.com/~lynn/subintegrity.html#3factor

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

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 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
https://www.garlic.com/~lynn/subpubkey.html#rpo


re:
https://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:
https://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
https://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
https://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
https://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the Internet
https://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
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Sun, 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
https://www.garlic.com/~lynn/submain.html#360pcm

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

a reference about the motivation (that i've used numerous times):
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm

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
https://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
https://www.garlic.com/~lynn/2007f.html#26 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007f.html#53 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#57 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs?
https://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation
https://www.garlic.com/~lynn/2007j.html#70 Using rexx to send an email
https://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
https://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.
https://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
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 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.
https://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
https://www.garlic.com/~lynn/submain.html#dumprx

some recent mention:
https://www.garlic.com/~lynn/2007i.html#44 latest Principles of Operation
https://www.garlic.com/~lynn/2007j.html#26 Even worse than UNIX
https://www.garlic.com/~lynn/2007j.html#27 Even worse than UNIX
https://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-existent. 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 transferred 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
https://www.garlic.com/~lynn/submain.html#360pcm

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

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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
https://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.
https://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

Refed: **, - **, - **, - **, - **, - **, - **
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:
https://www.garlic.com/~lynn/2007l.html#8 My Dream PC -- Chip-Based
https://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

Refed: **, - **, - **, - **, - **, - **, - **
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

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

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
https://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
https://www.garlic.com/~lynn/2006w.html#email870109
in this post
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

Eric writing 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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 litany 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
https://www.garlic.com/~lynn/subtopic.html#hacmp
scale-up work we had been doing
https://www.garlic.com/~lynn/lhwemail.html#medusa

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

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Mon, 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:
https://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 writing/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
https://www.garlic.com/~lynn/x959.html#x959

in the X9A10 working group. a couple somewhat related recent posts
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#12 My Dream PC -- Chip-based
https://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
https://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)
https://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
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#63 public key password authentication
https://www.garlic.com/~lynn/2007i.html#73 public key password authentication
https://www.garlic.com/~lynn/2007j.html#67 open source voting
https://www.garlic.com/~lynn/2007k.html#32 SSL Security
https://www.garlic.com/~lynn/2007k.html#55 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies
https://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
https://www.garlic.com/~lynn/submain.html#360pcm

was in the mainframe channel board attachment to 360/67 channel ... recent reference
https://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:
https://www.garlic.com/~lynn/2003.html#25 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2005o.html#36 Penn Central RR computer system failure?
https://www.garlic.com/~lynn/2006c.html#21 Military Time?
https://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
https://www.garlic.com/~lynn/2007h.html#77 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#1 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#2 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007i.html#46 Linux: The Completely Fair Scheduler
https://www.garlic.com/~lynn/2007j.html#76 Linux: The Completely Fair Scheduler

Non-Standard Mainframe Language?

Refed: **, - **, - **, - **, - **, - **
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
https://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
https://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
https://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
https://www.garlic.com/~lynn/2004j.html#58 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2005b.html#43 [Lit.] Buffer overruns
https://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:
https://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:
https://www.garlic.com/~lynn/index.html#glosnote

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

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Tue, 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:
https://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:
https://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007g.html#3 University rank of Computer Architecture
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran developer, dies

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

and somewhat related posts about distributed lock manager work in support of the above:
https://www.garlic.com/~lynn/2007i.html#50 John W. Backus, 82, Fortran developer, dies
https://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
https://www.garlic.com/~lynn/submain.html#shareddata

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

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

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: 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:
https://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#16 John W. Backus, 82, Fortran developer, dies

some cross-over from this "cobol" thread
https://www.garlic.com/~lynn/2007k.html#66 The top 10 dead (or dying) computer skills
https://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:
https://www.garlic.com/~lynn/2007f.html#47 Is computer history taught now?
https://www.garlic.com/~lynn/2007f.html#48 Is computer history taught now?
https://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:
https://www.garlic.com/~lynn/2007l.html#18 Non-Standard Mainframe Language?

when i was undergraduate, 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:
https://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
https://www.garlic.com/~lynn/submain.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
https://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
https://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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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::
https://www.garlic.com/~lynn/2007g.html#6 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#35 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007g.html#68 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007i.html#13 U.S. Cedes Top Spot in Global IT Competitiveness

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

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 30 May 2007 08:46:43 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
the original cluster scale-up 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:
https://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)
https://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?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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
https://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
https://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 unsuccessful, 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
https://www.garlic.com/~lynn/subtopic.html#hacmp

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

and somewhat referenced in these postings about old meeting
https://www.garlic.com/~lynn/95.html#13
https://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
https://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#19 John W. Backus, 82, Fortran developer, dies
https://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?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 unsuccessful, 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:
https://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?

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

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 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 catalog ... 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
https://www.garlic.com/~lynn/submain.html#bdam

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

Refed: **, - **, - **, - **, - **, - **, - **, - **
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" is bookmark folder (from bookmark table) ... and max(id) gets the most recent one, then all the bookmarks that have that folder as parent ... joined with the foreign key to the places (URL) table.

misc. past posts about original relational/sql implementation
https://www.garlic.com/~lynn/submain.html#systemr

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 16:21:15 -0600
Lawrence Statton <yankeeinexile@gmail.com> writes:
Likewise, my .emacs and .tcshrc are the current editions of files I've been carrying around with me since 1988.

i have an emacs implementation of xedit "all" command from about the same time-frame.

Virtual private networks

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual private networks
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 30 May 2007 17:14:09 -0600
kaja_love160 writes:
1) What is the main purpose of using VPN - the security of connection between LAN and a remote host or the fact that LAN servers think of remote PC as one of the local PCs?

recent post about proposal introduced at '94 IETF meeting in san jose ... that came to be called VPN
https://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored

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: Thu, 31 May 2007 06:32:04 -0600
jmfbahciv writes:
A typical system owner is going to assume that all tasks he does is privileged because he's the owner and should be the most important one. The meaning of the word privileged is going to have to be taught as we use it in this biz. Most users are going to associate the word with royalty and the social elite.

i've frequently claimed that part of this is because of systems that had grown up from disconnected, home table top environment. they were disconnected, personal systems that had no need for countermeasures and armoring to protect from hostile attacks. those early home systems and connecting to the internet have diametrically opposing design and implementation requirements ... at least the difference between a 2-seater, convertable sports car and a bradley.

semi-related item from today:

Security analogies: the key to educating laymen
http://www.theregister.com/2007/05/31/security_analogies/

and for other drift ... the "naked" payment/transaction analogy
https://www.garlic.com/~lynn/subintegrity.html#payment

and couple past posts mentioning the "after-market" security analogy
https://www.garlic.com/~lynn/2002h.html#39 Oh, here's an interesting paper
https://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules

Is Parallel Programming Just Too Hard?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Parallel Programming Just Too Hard?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 31 May 2007 08:26:47 -0600
Quadibloc <jsavard@ecn.ab.ca> writes:
But even with those results, the book does speak of multithreading as something needed for the future so as to exploit the parallelism inherent in pipelined architectures. (The book appears to have been written before Intel came out with its HyperThreading version of the Pentium. Although "hyper" seems like an odd adjective when only two threads are involved.)

So even without adoption of parallel algorithms, the exploitation of implicit parallelism in programs by the computers themselves appears to be growing slowly.


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

some amount of parallelism has to do with degree/frequency of synchroniziation & serialization ... this can somewhat seen in loosely-couple/cluster configurations ... the degree of synchronization frequently involves the bandwidth of the communication mechanism, the latency of the communication mechanism and the overhead of the communciation (high-overhead & high-latency would contribute to strategies involving less frequent synchronization).

out-of-order execution tends to have to do with (relative) high cache-miss memory latency (stalling current instruction) ... but along with relatively large cache resulting in decent probability that subsequent instructions might not have cache miss.

problem is that current serial programming paradigm has relatively high instruction-to-instruction synchronization. hardware supporting out-of-order execution somewhat is attempting to dynamically discover places where there might not be instruction-to-instruction synchronization. this is somewhat chip design being forced into attempting to compensate for the serial programming paradigm.

i've mentioned before one of the early efforts (that wasn't released) for multi-threading was 370/195 project in the 70s to add 2nd thread to the machine. peak thruput was around 10mips ... but most codes ran around 5mips because of branches stalling pipeline operation. Idea was that adding a second thread (simulating multiprocessor operation) had chance of keeping processor resources operating at 100% utilization (for minimal extra hardware) ... providing some additional "decoupled" instruction-to-instruction serialization.

holy grail changing the software paradigm is to achieve potentially orders of magnitude more parallelism ... leading to higher aggregate thruput (and/or being able to have results in much shorter elapsed time) ... both "tightly-coupled" single chip operation as well as large numbers of "loosely-coupled" chips (some of the uptake of large GRID configurations is now by trading houses attempting to do calculations for nearly "real-time" trades).

By comparison some of the current chip design approach is attempting to devote more and more hardware resources to (dynamically) discover smaller and smaller incremental thruput in strictly serial execution.

most past posts mentioning 70s project for multi-threaded, dual-istream 370/195:
https://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
https://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
https://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
https://www.garlic.com/~lynn/2003j.html#41 Of what use 64-bit "General Purpose" registers?
https://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2006c.html#29 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#10 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006r.html#2 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007i.html#45 IBM System/360 Model 85: The Bashful Computer

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Fri, 01 Jun 2007 11:26:25 -0600
Greg Menke <gdmnews@toadmail.com> writes:
The crypto only protects the "permission slip". Validation and verification of the slip itself is a separate issue. THere are plenty of ways keys can be created and distributed, the problem is ensuring both parties in the transaction have appropriate controls, meaning, neither party has unilateral control.

Ideally the payer would generate a key of two parts, one given to the bank and the other to the payee. The bank uses its part to verify the payee's part- if the algorithms pass the keys as matching then the payment is made and the bank discards its key. Presumably the amount of payment would be encoded with the keys so the right amount is paid. But all this requires a banking system that cares, which is manifestly not the case.


and/or banking systems that are forced to meet controls.

part of the key issue in x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

& aads
https://www.garlic.com/~lynn/x959.html#aads

... is that the transaction is armored with digital signature ... which changes on every transaction. that eliminates evesdropping attacks (harvesting, skimming, data breaches, security breaches, etc) involving previous transactions for replay attacks. it also eliminates having to actually encryption of the transaction to hide its contents ... since the contents of previous transactions are no longer useful in (replay attacks) in future fraudulent transactions.
https://www.garlic.com/~lynn/subintegrity.html#harvest

the current infrastructure with "cards" ... is a something you have operation ... from 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor
something you havesomething you knowsomething you are

however, the "proof" of the something you have is the contents of the magstripe on the card ... which is "static" data ... which can be skimmed/harvested (obtained from previous transactions) and relatively trivially used to generate counterfeit cards.

even some of the card "chip-based" infrastructures have also relied on "static data" verification ... which is also vulnerable to skimming/harvesting exploits and the creation of counterfeit cards ... some specific discussions
https://www.garlic.com/~lynn/subintegrity.html#yescard

digital signatures is dynamic data that uses public/private key technology. the private key is kept confidential and never divulged. the public key is openly registered ... and is used to verify the digital signature. the public key can't be used for originating a digital signature. some recent posts
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies

it is not usefual in (secret key) impersonation attacks (like passwords and pins) ... where the same value is used for both originating an authentication and verifying an authentication (and therefor the verifying value is vulnerable to attacks/insiders using it for impersonation)
https://www.garlic.com/~lynn/subintegrity.html#secrets

the "private key" is actually known (like in the case of pins/passwords for something you know) ... but is kept encapsulated in some device that actually performs the digital signature (and therefor becomes something you have authentication). however, it is vulnerable to divulging and counterfeiting (analogous to current card magstripe).

the issue then becomes the degree of armoring provided by the device that holds the "private key". in the 90s the claim was the really expensive chips that provided such armoring and countermeasures for divulging (the private key) were way to expensive for common use. that was one of our semi-facetious comments about taking a $500 mil-spec piece and aggresively cost reducing it by 2-3 orders of magnitude while not sacrificing any of the armoring and countermeasure technologies ... aka the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

the exploits then shifts away from data breaches (mostly someplace in the merchant infrastructures, not only from external attackers but also long term stats are that "insiders" are typically involved in approx. 70percent of the incidents) ... being able to harvest details on 40million accounts out of previous electronic transactions ... account having to physically steal each (account) token. this is somewhat the old post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

Such a shift drives up the per account fraud cost to the attacker enormously. The other issue is that lost/stolen "reports" have been an effective countermeasure to limiting the amount of fraud. In the skimming/harvesting (and data breach) scenarios, awareness that something has been stolen is signficiantly delayed (until after fraud is starting to happen). Shifting the thefts back to physical objects ... there is much higher probability that the theft will be noticed and reported before significant amounts of fraud has occurred.

if an aads digital signature token is augmented with some sort of PIN that additional drives down the fraud exposure. normally multi-factor authentication is considered more secure when the different factors have different vulnerabilities ... i.e. PINs (something you know) have been considered countermeasure to "lost/stolen" card/tokens (something you have). However, that assumption may be invalidated in some of the skimming/harvesting attacks ... where the "static" magstripe data (as evidence of something you have) and the "static" PIN data can be skimmed/harvested in a common operation. With the x9.59/AADS scenario, a PIN operation is vulnerable to skimming ... but the ("unique") token isn't. The token is still vulnerable to physical theft ... but the countermeasures can be both a something you know PIN (and/or a something you are biometric) as well as lost/stolen reports (you become aware that you no longer have a physical object, as opposed to some piece of information related to you has been stolen/compromised; which is significantly harder to discover and rectify).

part of the current infrastructure is that US financial infrastructures are reported to make nearly 40percent of their bottom line off payment operations. part of this is the "interchange fees" (charged merchants) which can be considered (at least partially) a type of fraud insurance (spread across all the merchants) ... since so much of the current fraud can arise from exploits in the merchant infrastructure. x9.59/aads eliminates many of those vulnerabilities (which potentially might be used as an excuse for drastically reducing "interchange fees"). recent posts mentioning interchange fees:
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#72 Free Checking

Part of this dates back to the mid-90s when the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. This, in turn, led to detailed end-to-end theat, vulnerabiilty and exploit analysis ... and attempting to formulate cost-effective countermeasures for those threats, vulnerability, and exploits ... and was behind of much of the motivation in the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

Questions to the list

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Questions to the list
Newsgroups: bit.listserv.ibm-main
To: <ibm-main@bama.ua.edu>
Date: Fri, 01 Jun 2007 11:34:57 -0600
Tom.Schmidt@ibm-main.lst (Tom Schmidt) writes:
It seems to me that only a few years ago (and probably in many of the hundreds of recycled "I remember when..." threads lately) we were, as a group, lamenting that we were all getting older and there was little new blood being introduced to the mainframe. We were also having 'sour grapes' discussions about workload moving off the mainframe and companies abandoning the mainframe altogether.

one of the issues ... especially on the usenet side ... was that the start of each new semester ... there would be a some new flurry of homework questions ... as individuals taking a computer class and getting possibly their first exposure to terminals and online infrastructures. as online infrastructures starting to permeate the whole culture ... it is now possible to find homework questions happening all thru the yr.

there is some balance between answering questions where the askee has actually made some attempt to learn something ... or is using the list in lieu of having to learn anything.

misc. past posts mentioning homework issue:
https://www.garlic.com/~lynn/2000.html#28 Homework: Negative side of MVS?
https://www.garlic.com/~lynn/2000.html#32 Homework: Negative side of MVS?
https://www.garlic.com/~lynn/2001.html#70 what is interrupt mask register?
https://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
https://www.garlic.com/~lynn/2001c.html#11 Memory management - Page replacement
https://www.garlic.com/~lynn/2001c.html#25 Use of ICM
https://www.garlic.com/~lynn/2001k.html#75 Disappointed
https://www.garlic.com/~lynn/2001l.html#0 Disappointed
https://www.garlic.com/~lynn/2001m.html#0 7.2 Install "upgrade to ext3" LOSES DATA
https://www.garlic.com/~lynn/2001m.html#32 Number of combinations in five digit lock? (or: Help, my brain hurts)
https://www.garlic.com/~lynn/2002c.html#2 Need article on Cache schemes
https://www.garlic.com/~lynn/2002f.html#32 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002f.html#40 e-commerce future
https://www.garlic.com/~lynn/2002g.html#83 Questions about computer security
https://www.garlic.com/~lynn/2002l.html#58 Spin Loop?
https://www.garlic.com/~lynn/2002l.html#59 Spin Loop?
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#35 META: Newsgroup cliques?
https://www.garlic.com/~lynn/2003d.html#27 [urgent] which OSI layer is SSL located?
https://www.garlic.com/~lynn/2003j.html#34 Interrupt in an IBM mainframe
https://www.garlic.com/~lynn/2003m.html#41 Issues in Using Virtual Address for addressing the Cache
https://www.garlic.com/~lynn/2003m.html#46 OSI protocol header
https://www.garlic.com/~lynn/2003n.html#4 Dual Signature
https://www.garlic.com/~lynn/2004f.html#43 can a program be run withour main memory ?
https://www.garlic.com/~lynn/2004f.html#51 before execution does it require whole program 2 b loaded in
https://www.garlic.com/~lynn/2004f.html#61 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004h.html#47 very basic quextions: public key encryption
https://www.garlic.com/~lynn/2004k.html#34 August 23, 1957
https://www.garlic.com/~lynn/2005h.html#1 Single System Image questions
https://www.garlic.com/~lynn/2005m.html#50 Cluster computing drawbacks
https://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
https://www.garlic.com/~lynn/2006b.html#2 Mount a tape
https://www.garlic.com/~lynn/2006h.html#40 Mainframe vs. xSeries
https://www.garlic.com/~lynn/2006l.html#54 Memory Mapped I/O Vs I/O Mapped I/O
https://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology

Friday musings on the future of 3270 applications

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Friday musings on the future of 3270 applications
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Fri, 01 Jun 2007 12:00:03 -0600
rsmrcina@ibm-main.lst (Rich Smrcina) writes:
If I understand what your asking there are products on the market that can do this today.

As long as there is a 3270 on the back end (specifically TN3270), a web interface or a web service is presented on the front end.


part of this is some of the whole history about terminal emulation. 3270 terminal emulation contributed significantly to early uptake of ibm/pc ... i.e. businesses that had already allocated money for 3270 terminal ... it became nearly no-brainer ... to switch to an ibm/pc ... price was about the same ... and in single desktop footprint the business got both 3270 terminal and some possibly added-value local computing.
https://www.garlic.com/~lynn/subnetwork.html#emulation

this contributed to significant install base of 3270 terminal and terminal emulation products.

in the later part of the 80s ... were had come up with 3-tier architecture (as an enhancement to client/server)
https://www.garlic.com/~lynn/subnetwork.html#3tier

and were out doing some amount of customer executive presentations ... and taking a lot of heat from the T/R and SAA forces(to some extent SAA could be viewed as attempting to help preserve the terminal emulation paradigm and inhibit the spread of client/server ... and especially this new fangled 3-tier stuff).

we also were taking some amount of heat working with organizations around the nsfnet backbone effort (i.e. tcp/ip is considered the technology basis for the modern internet but nsfnet backbone would be considered the operational basis for the modern internet). some old email from the period on the topic
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

and after starting to cancel our meetings with outside entities ... then there was suggestion that they should start proposing SNA/VTAM as the basis for nsfnet backbone ... specific old email reference
https://www.garlic.com/~lynn/2006w.html#email870109
in this post
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET

one of the side happenings in all this was we did get an NSF audit of high-speed backbone we had running internally
https://www.garlic.com/~lynn/subnetwork.html#internalnet

which concluded that what we had running was at least five yrs ahead of all NSFNET backbone bids (to build something new)

and for some topic drift ... tagential reference here
https://www.garlic.com/~lynn/2007l.html#14 Superconductors and computing

Is Parallel Programming Just Too Hard?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Parallel Programming Just Too Hard?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Fri, 01 Jun 2007 12:07:53 -0600
re:
https://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#26 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#34 Is Parallel Programming Just Too Hard?

recent news items

Intel Pledges 80 Core Processor in 5 Years
http://hardware.slashdot.org/hardware/06/09/26/1937237.shtml
Intel shows off 80-core processor
http://news.com.com/Intel+shows+off+80-core+processor/2100-1006_3-6158181.html
Next Windows To Get Multicore Redesign
http://developers.slashdot.org/article.pl?sid=07/05/31/1257231

part of the issue is that a lot of the parallel processing has been limited to high-end market ... where highly skilled programming could be used to manage large amount of shared resources ... effectively concurrently working on different activity from independent sources.

as parallel hardware has started to move downstream into standard consumer market ... issues in the past couple yrs is how to change the (mostly) sequential programming paradigm to better utilize the independent/parallel hardware resources that are available.

the hardware technology motivation is that as components are shrinking ... things like signal latency and synchronized, serial operation are starting to represent a significant limiting factor ... going to asynchronous operation ... even across the distances involved in a typical chip ... can contributed to significant thruput increases.

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Fri, 01 Jun 2007 13:24:59 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
But you miss the point: The chip *never* divulges the private key. It *can't*. The only "armoring" involved being the mere ability to encrypt using that hidden key that cannot be accessed in any other way. Public Key Encryption algorithms really aren't *that* difficult for a rather small chip to handle these days.

re:
https://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based

have you seen things like differential power analysis?

have you ever peeled a chip ... and used an electron microscope for looking at chip operation?

... slight topic drift ... los gatos vlsi lab was one of the first in using electron microscope in analysing chip operation ... although it was for debugging purposes ... not as an attack/exploit.

in general, if it is sufficiently valuable ... the resources can be spent to obtain the information. part of the issue in x9.59/aads was to eliminate any single (or small number) of key vulnerabilities that might represent a systemic risk for the whole infrastructure. Each key applied to potentially a single (or small number of accounts) ... limiting the risk exposure related to that specific key. then in the lost/stolen scenario ... have the chip protection such that the key extraction was likely to cost more than the value in the accounts (and/or take longer than the typical lost/stolen report that would result in invalidating the key). as i referred to in the previous post ... this was a detailed end-to-end systemic analysis of threats, vulnerabilities, exploits, etc. It wasn't just limited to simple, single point considerations ... nearly all possible attacks/exploits had to be considered and appropriate countermeasures planned for.

in the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

i was able to get an (common criteria) EAL4+ evaluation ... in some cases using nearly identical chip that others were getting an EAL5+ evaluation.

part of the issue here was in the aads chip strawman ... everything is manufactured into the chip silicon (it wasn't possible to load any applications after manufacturing ... part of aggresive infrastructure cost reduction) ... even the (ECC) crypto ... so a an EAL5+ evaluation requires a semi-formal definition of the crypto to evaluate against (and at the time, NIST had just pulled its reference critera for ECDSA).

The EAL5+ evaulations on similar chips were scenarios where they allowed post-manufacturing loading (aka the chip could be evaluated w/o any applications, since the crypto and other stuff went on afterwards).

We claimed that the ability to load, was in fact a vulnerability ... and so the aads chip strawman EAL4+ actually represented higher integrity than the EAL5+ and EAL6+ evaluations of similar chips.

one of the issues in the whole x9.59/aads security proportional to risk ... was being able to have original chip integrity characteristics as well as possibly integrity characteristics that the digital signing was occurring in ... to allow things like dynamic risk assessement on transaction by transaction basis ... aka do things like taking in a specific chips integrity characteristics (and attack countermeasures) when evaluated whether a specific transaction should be approved (i.e. where there might be a broad range in the value of the transactions and the integrity level of individual chips ... all supported by a single infrastructure).

there has been some discussions about something you have and something you know authentication ... but there is also attack, threat, exploit, vulnerability issues related to the environment that a digital signature occurs ... some of this is discussed in a series of posts mentioning the EU FINREAD ("financial reader") terminal standard
https://www.garlic.com/~lynn/subintegrity.html#finread

quicky use of search engine for some misc. references to various chip attacks, threats, vulnerabilities, etc
http://www.cryptography.com/resources/whitepapers/DPA.html
https://en.wikipedia.org/wiki/Power_analysis
http://citeseer.ist.psu.edu/kocher99differential.html
http://www.research.ucla.edu/tech/ucla04-155.htm

in general, to really defend ... you also have to be able to think like an attacker ... in order to anticipate the types of attacks that you are defending from. one of our past jokes about some defenses/countermeasures being equivalent to placing a 6ft thick bank vault in the middle of an open field ... with no sides, ceilings, floor, etc. the other scenario in security proportional to risk ... is that it is difficult to justify costs of anti-fraud measures that are significantly larger than the fraud that is supposed to be prevented.

some past posts mentioning EAL4+, common criteria, chip attacks, etc:
https://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition for eal 5/6 evaluation
https://www.garlic.com/~lynn/2002k.html#35 ... certification
https://www.garlic.com/~lynn/2002m.html#44 Beware, Intel to embed digital certificates in Banias
https://www.garlic.com/~lynn/2002m.html#72 Whatever happened to C2 "Orange Book" Windows security?
https://www.garlic.com/~lynn/2003c.html#39 DOD 5200.28-STD capable OS?
https://www.garlic.com/~lynn/2003k.html#51 Linux gets sensitive government use approval
https://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
https://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/2004m.html#41 EAL5
https://www.garlic.com/~lynn/2006t.html#38 Vulnerability Assessment of a EAL 4 system
https://www.garlic.com/~lynn/2007b.html#30 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless)

some past posts mentioning that various parts of the current infrastructure contributes to attackers being able to outspend the defenders potentially by a factor of 100:1
https://www.garlic.com/~lynn/aadsm26.htm#58 Our security sucks. Why can't we change? What's wrong with us?
https://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies

for lots of drift ... various past posts mentioning los gatos vlsi lab:
https://www.garlic.com/~lynn/2000.html#16 Computer of the century
https://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001h.html#29 checking some myths.
https://www.garlic.com/~lynn/2002q.html#19 Beyond 8+3
https://www.garlic.com/~lynn/2002q.html#45 ibm time machine in new york times?
https://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
https://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
https://www.garlic.com/~lynn/2003o.html#21 TSO alternative
https://www.garlic.com/~lynn/2004f.html#7 The Network Data Model, foundation for Relational Model
https://www.garlic.com/~lynn/2004f.html#42 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#1 4shift schedule
https://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#0 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
https://www.garlic.com/~lynn/2007b.html#27 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007d.html#27 modern paging
https://www.garlic.com/~lynn/2007h.html#41 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
https://www.garlic.com/~lynn/2007j.html#24 Newbie question on table design

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Fri, 01 Jun 2007 13:40:05 -0600
re:
https://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based

it isn't if or can they ... it is how much is it going to cost and how long will it take ... 1) make it more expensive than any expected benefit to the attacker (i.e. security proportional to risk) and/or 2) make it so expensive to attack (and the resulting fraud ROI so small) that they go somewhere else (that is easier)

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Fri, 01 Jun 2007 16:58:54 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
Yes, and again there are *easy* methods to hide such things from peeking eyes, that cannot be defeated except by destroying what you're looking for. You're talking to an engineer here.

It's true that there's NO completely "safe" method, if you have the total system in-hand. However, your common criminal isn't going to have such tools at hand; nor would it do him much good anyway; as the cost of such tools would be FAR greater than he/she would ever recover from compromising credit-cards; and also the amount of energy spent on each card to recover an internal key would begin to rival the maximum possible to recover from such a card. Diminishing returns.

Such methods are really only useful in spy cases or similar methods where the value of the DATA itself is enormous; and not the measly amounts a person might get from somebody's credit-card; which in any case would soon be shut off by the issuer once it became obvious this wasn't the sort of spending said consumer used normally.


re:
https://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#40 My Dream PC -- Chip-Based

so destroy the original ... and then replace it with a copy-chip that does a good enuf job of emulation ... call it a doppleganger ... question is how long does the whole process take. or some other really advanced nonintrusive techniques that don't even have to destroy the original (it is somewhat a constant ongoing battle with new attacks requiring new countermeasures).

note that the YES CARD chip exploit is similar but different
https://www.garlic.com/~lynn/subintegrity.html#yescard

two issues ... is can i use the process/equipment against a large number of different tokens (justifying the cost) or are there tokens that represent particular specific vulnerabilities (aka some people might do $20 transactions and others might do $1m transactions) and/or overall systemic risks, that might justify the effort.

the EU FINREAD standard
https://www.garlic.com/~lynn/subintegrity.html#finread

has to do with whether the transaction that you think you are approving/authorizing (displayed by the terminal) is actually the transaction that you are approving/authorizing (by using the something you have token to generate a digital signature). another kind of exploit/vulnerability that doesn't require direct compromise of your chip/token.

one of the issues in doing aads
https://www.garlic.com/~lynn/x959.html#aads
and the financial industry standard
https://www.garlic.com/~lynn/x959.html#x959

in some quarters there is automatic kneejerk reaction that if you say public key ... there are automatic assumptions about certification authorities and PKI operations.

this was avoided in basic aads/x9.59 work because of perceived systemic risks ... so a certificate-less public key operation is defined
https://www.garlic.com/~lynn/subpubkey.html#certless

and old email reference discussing certificate-less public key operation
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12 more secure communication overthe network

so, in this recent thread there is some discussion about PKIs and certificate-based operations ... especially around its application to SSL
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?

aka ... we had been called into consult with this new client/server startup that wanted to do payment transactions on their servers ... and they had some technology they called SSL ... minor reference
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

and lots of other posts mentioning SSL and SSL related infrastructure
https://www.garlic.com/~lynn/subpubkey.html#sslcert

one of the issues in PKI infrastructure ... it isn't the use of a specific private key in digital signatures representing something you have authentication ... it is what a "digital certificate" says about you and the "public key" (that is paired with your "private key").

as mentioned in the above referenced thread ... typical browser might have 40-50 different public keys (in the trusted public key repository) ... and compromise against any particular (certification authority) key ... is sufficient to compromise the whole infrastructure (systemic risk) ... aka extract a specific private key (w/o leaving traces) ... and then be able to use that extracted/compromised private key to generate "valid" digital certificates for everybody (somewhat like some of spy stories about stealing valid plates, paper, & ink in order to print your own counterfeit money) ... specifying public/private keys in the possession of the attackers ... aka ... they don't have to find out your private key ... they just have to "print" a valid digital certificate that says it applies to you ... and specifying a public key that they control.

lots of posts about various kinds of fraud, threats, vulnerabilities, exploits, etc
https://www.garlic.com/~lynn/subintegrity.html#fraud

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Fri, 01 Jun 2007 17:25:28 -0600
for the fun of it ... a little x-over between the recent "authentication" and "integrity" subthread
https://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#40 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#41 My Dream PC -- Chip-Based

and the "Is Parallel Programming Too Hard?" thread
https://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#34 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#38 Is Parallel Programming Just Too Hard?

besides multi-core ... lots of past multiprocessor related posts
https://www.garlic.com/~lynn/subtopic.html#smp

... the other parallel programming venue is the massive GRIDs ... even further scale-up than what we had started for ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

... old email references
https://www.garlic.com/~lynn/lhwemail.html#medusa

a lot of the medusa "cluster-in-a-rack" (with potentially large number of racks) was physical packaging placing higher and higher density of commodity computing components in smaller & smaller footprint. A current generation of that physical packaging (in large part originally done for GRID) is called blades ... and you are seeing the vendors trying to move the technology out of the purely numerical intensive environments and more & more into various commercial sectors.

in any case, there is a reference here to an "authentication" & "integrity" talk that i gave at an annual GRID conference:
https://www.garlic.com/~lynn/index.html#presentation

one scenario being what if an attacker could compromise a very large GRID installation, turning it into a massive "botnet"

another "authentication" talk I gave was at an assurance panel in the TPM (trusted process module) track at an Intel Developer's conference. I've joked before that the guy running the TPM effort was in the front row ... and that I quipped it was nice to see that over the previous couple years the TPM chip definition had started to look more and more like the AADS chip strawman. He quipped back ... that I didn't have a committee of a couple hundred helping me with chip design.

A recent post mentioning have looked at a solution with some of the TPM characteristics when the original PC came out
https://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools

a couple past posts mentioning the talk in the TPM track at an Intel Developer's forum
https://www.garlic.com/~lynn/2001d.html#58 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2006h.html#31 Intel vPro Technology

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Fri, 01 Jun 2007 17:41:50 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
But that won't WORK! The doppleganger *must* have the original key to properly encode the data *with that same private key*; and if it has *that*, then why bother with the doppleganger at all?

re:
https://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#40 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#41 My Dream PC -- Chip-Based

the issue is whether the private key extraction is invasive or not ... there are some techniques that are destructive and require a doppleganger to hide the fact that it has happened (and there are some number of noninvasive/nondestructive techniques). the issue is somewhat like all the data breaches ... there is significantly more fraud potential if the victims are kept unaware of the compromise for as long as possible.

this somewhat flows over into the previous discussion mentioning institutional centric tokens vis-a-vis person-centric tokens. one of the infrastructure issues in the institutional centric operations is the extremely high security (and the associated costs) that has to be maintained between the chip fab and any personalization (software loading, key loading, etc) that must occur before final delivery of the token to the individual.

the claim frequently was that the extremely high (& costly) security (before final delivery) was necessary to make sure that copy/counterfeit chips hadn't been introduced into the supply chain. the effort for enabling a transition from institutional centric operation to a person-center paradigm ... was to provide some high assurance mechanism that a person "presented" token (for use at an institution) would be just as good as any institution provided token.

not only did it eliminate the high/costly (post chip-fab) security (part of the aads chip strawman aggresive per token cost reduction) ... but any really "successful" institutional centric effort would mean that individuals would have a token in place of every (physical) key, password, and PIN (potentially a hundred or more per person). part of any successful aads chip strawman effort, not only significantly reduced the (total end-to-end, fully loaded) per token related costs ... but also enabling the person-centric paradigm would also significantly reduce the total number of tokens that would be needed (i.e. 2-3 orders of magnitude in per token fully loaded costs and potentially another 2-3 orders of magnitude in the total number of tokens ... possibly overall reduction of 4-6 orders of magnitude) ... recent reference
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies

internet game history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: internet game history
Newsgroups: alt.folklore.computers
Date: Fri, 01 Jun 2007 18:01:49 -0600
late 70s(?) ... a multi-user "space war" game was done that ran on the internal network (written by the author of rexx) ... you had to put up server and then ran client application in each private cms (cms clients could be time-shared on the same real machine as the game server and/or on other real machines networked to the machine running the game server) ... the client application then was responsible for sending moves to the server and receiving "screen" updates (from the server) and displaying them.

within a couple weeks client "bots" had been created (in place of the standard client app) that would beat all the human players (mostly because their reaction time for moves/actions was much faster).

then the game/server was retrofitted with adjustment that as the interval between individual moves/actions dropped below a (human reaction) threshold ... there was non-linear increase in energy used. bots weren't disallowed ... but the non-linear increase in energy used was to somewhat level the playing field between humans playing and the bots.

so one thing interesting aspect of multi-user networked game history was when/where did game bots put in their appearance.

internet game history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: internet game history
Newsgroups: alt.folklore.computers
Date: Sat, 02 Jun 2007 03:20:19 -0600
re:
https://www.garlic.com/~lynn/2007l.html#44 internet game history

previous post
https://www.garlic.com/~lynn/2005u.html#4 Fast action games on System/360+?

with small snippet from MFF client source (circa summer 1980)

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Sat, 02 Jun 2007 03:37:55 -0600
some posts that reference a risk digest with an item on "nothing succeeds like failure" ...
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/aadsm26.htm#59 On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Sat, 02 Jun 2007 04:00:41 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
have you ever peeled a chip ... and used an electron microscope for looking at chip operation?

... slight topic drift ... los gatos vlsi lab was one of the first in using electron microscope in analysing chip operation ... although it was for debugging purposes ... not as an attack/exploit.


re:
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#40 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#41 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#42 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#43 My Dream PC -- Chip-Based

for other topic drift ... los gatos lab also worked on ibm's original atm (cash) machine (also makes reference to early PIN-block vulnerability)
https://www.garlic.com/~lynn/2006q.html#5
https://www.garlic.com/~lynn/2006u.html#40
https://www.garlic.com/~lynn/2006x.html#9

and news item from today ...

Would you credit it? The debit card turns 20
http://www.silicon.com/financialservices/0,3800010322,39167351,00.htm?r=1

which would make it 1987 ... however the previous posts have references for the 2984 as 1972 (15 yrs earlier), 3614 in 1973, and the 3624 in 1979 aka they must be making some distinction "debit" cards and ATM machine "debit" cards

My Dream PC -- Chip-Based

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: My Dream PC -- Chip-Based
Newsgroups: alt.folklore.computers
Date: Sat, 02 Jun 2007 09:36:32 -0600
Frank McCoy <mccoyf@millcomm.com> writes:
It's true that there's NO completely "safe" method, if you have the total system in-hand. However, your common criminal isn't going to have such tools at hand; nor would it do him much good anyway; as the cost of such tools would be FAR greater than he/she would ever recover from compromising credit-cards; and also the amount of energy spent on each card to recover an internal key would begin to rival the maximum possible to recover from such a card. Diminishing returns.

oh ... and my oft repeated reference to security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

which then flows into the observation that (for the scenario involving credit card accounts), attackers can afford to outspend the defenders by possibly as much as 100:1. recent posts mentioning attackers can outspend defenders by possibly 100:1
https://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based

one of the upswings in the early to mid 90s was a class of extremely skilled and highly technical criminal attackers ... something that many had been claiming would never possibly occur ... i.e. criminals were frequently assumed to be bumbling bank robbers with guns and lacking a high school education.

re:
https://www.garlic.com/~lynn/2007l.html#43 My Dream PC -- Chip-based

so for PKI & certification authority related infrastructure ... it turns out to not be necessary to even attack the individual account hardware tokens ... it would only be sufficient to attack the hardware token of a certification authority ... since in a PKI infrastructure ... it isn't what is onfile about you ... but what a valid digital certificate claims about you. you obtain the private key of any of the valid trusted certification authorities ... possibly by destructive process, substitute the doppleganger, and then start minting your own digital certificates for all your friends ... which make claims about existing accounts but specifies their own public keys (not the real account holders public keys).

one of the reasons that the detailed, end-to-end threat & vulnerability analysis (as part of the x9.59 financial standards work) that PKI & certification authority infrastructures were treated as systemic risks
https://www.garlic.com/~lynn/x959.html#x959

... as well as treating digital certificates as obsolete and adding enormous redundant and superfluous payload and processing bloat in the case of payment transactions
https://www.garlic.com/~lynn/subpubkey.html#bloat

including a few recent threads/discussions
https://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardised Security Protocols are Too Heavy
https://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored
https://www.garlic.com/~lynn/2007j.html#67 open source voting
https://www.garlic.com/~lynn/2007l.html#16 John W. Backus, 82, Fortran developer, dies

Drums: Memory or Peripheral?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Drums: Memory or Peripheral?
Newsgroups: alt.folklore.computers
Date: Sun, 03 Jun 2007 09:17:03 -0600
Peter Flass <Peter_Flass@Yahoo.com> writes:
Not in my understanding. A "track" was/is one run around one platter at a given head position. A "cylinder" was/is the set of tracks in the same head position across all platters. Probably John has a diagram somewhere in that encyclopedia of computer architecture he's building.

mainframe DASD (aka generic term from before it was apparent what form factor might come to dominate) addressing has been BBCCHHR ... i.e. bin, bin, cyliner, cylinder, head, head, record.

in disk form factor, cylinder refers to the arm position and head refers to the specific head on the arm. however, there are also references to TTR and the number of tracks per cylinder (i.e. number of surfaces).

"BB" was used in 2321 data-cell ... where there were multiple "bins" of data strips ... the bins were formed into somewhat physical cylinder configuration that rotated (somewhat like washing machine) the desired bin (collection of data strips) under head position.

picture of both 2303 drum, 2321 datacell, and 2311 disk
http://www.beagle-ears.com/lars/engineer/comphist/c20-1684/fig043.jpg

2301 & 2303 were physically similar ... except 2301 read/writes four heads in parallel ... for four times the data transfer rate of 2303

RPS (rotational position sensing) was introduced with 3330 DASD ... there were 20 surfaces ... but only 19 addressable track/heads ... the 20th head/track was used to keep "track" of the rotational position.

in cp67 and vm370, especially for paging ... there was a lot of optimization related to attempting to transfer as much data per revolution. queued/pending requests might include some number of requests for the same cylinder (arm position) but different tracks. building the channel programs so that order of page transfers selected corresponding to the sequential rotational position ... even if located on different tracks.

the original cp67 installed at the university when i was an undergraduate had purely FIFO single request transfer at a time. For 2301, this would peak out at about 80 page transfers/second under heavy load. I rewrote the code so that it would build chained I/O of pending requests, ordered so as to maximize transfers per revolution ... being able to hit 300 page transfers/second (under heavy load) ... which was the theoretical maximum for the 2301. For disks, I also replaced the FIFO (cylinder) request order ... with ordered-seek-queueing ... and for paging requests ... would chain together all requests at the same arm positioning ... again reordering them to attempt to achieve maximum transfers per revolution. Non-paging disks requests ... like for cms filesystem, etc ... then weren't subject to the ordered-seek queueing rewrite ... but different requests would be reordered for the same arm position ... I did "correct" this a couple years later when i did page-mapped implementation for the cms filesystem (in the early 70s)
https://www.garlic.com/~lynn/submain.html#mmap

a few recent posts mentioning ordered seek queueing
https://www.garlic.com/~lynn/2007e.html#33 IBM S/360 series operating systems history
https://www.garlic.com/~lynn/2007e.html#40 FBA rant
https://www.garlic.com/~lynn/2007g.html#12 University rank of Computer Architecture
https://www.garlic.com/~lynn/2007k.html#17 John W. Backus, 82, Fortran developer, dies

some recent posts mentioning 2321 data cell
https://www.garlic.com/~lynn/2007e.html#38 FBA rant
https://www.garlic.com/~lynn/2007e.html#51 FBA rant
https://www.garlic.com/~lynn/2007e.html#63 FBA rant
https://www.garlic.com/~lynn/2007e.html#64 FBA rant
https://www.garlic.com/~lynn/2007f.html#0 FBA rant
https://www.garlic.com/~lynn/2007f.html#3 FBA rant
https://www.garlic.com/~lynn/2007f.html#5 FBA rant
https://www.garlic.com/~lynn/2007f.html#12 FBA rant
https://www.garlic.com/~lynn/2007f.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#9 Newbie question on table design

other recent posts mentioning 2301 (drums)
https://www.garlic.com/~lynn/2007e.html#38 FBA rant
https://www.garlic.com/~lynn/2007e.html#64 FBA rant
https://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
https://www.garlic.com/~lynn/2007g.html#33 Wylbur and Paging
https://www.garlic.com/~lynn/2007k.html#16 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#38 John W. Backus, 82, Fortran developer, dies

Scholars needed to build a computer history bibliography

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scholars needed to build a computer history bibliography
Newsgroups: alt.folklore.computers
Date: Sun, 03 Jun 2007 09:29:28 -0600
Louis Krupp <lkrupp@pssw.nospam.com.invalid> writes:
Anyone else read "A Canticle for Leibowitz"?
https://en.wikipedia.org/wiki/A_Canticle_for_Leibowitz


i.e. required reading in high school (at least in 60s), not to discriminate too much against the more venerable members of the group (who attended high school before it was published).

there was period in the early/mid 90s ... where there was some fashion to refer to it ... related to the literacy studies/comparisons from the period (common phrase was the dumbing of america) ... predicting that things would go out more with a wimper than a bang ... somewhat more analogous to the fall of rome.

recent posts/threads discussing the literacy issue
https://www.garlic.com/~lynn/2007g.html#7 U.S. Cedes Top Spot in Global IT Competitiveness
https://www.garlic.com/~lynn/2007i.html#24 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#31 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#51 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#58 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#80 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#82 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#85 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#10 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#30 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#34 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#42 IBM Unionization
https://www.garlic.com/~lynn/2007l.html#5 IBM Unionization

Scholars needed to build a computer history bibliography

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scholars needed to build a computer history bibliography
Newsgroups: alt.folklore.computers
Date: Sun, 03 Jun 2007 09:44:10 -0600
Larry__Weiss <lfw@airmail.net> writes:
I liked that story too.

The long-term document preservation in it was as accidental as finding some of these older computer system docs we are scanning today in a box in our garage after thirty years or more of collecting dust.

Can our archives survive another "Simplification" ?


i've managed to preserve bits & pieces ... including references to posts of old email
https://www.garlic.com/~lynn/lhwemail.html

however, I "lost" quite a bit from the 60s and 70s ... when almaden tape library was experiencing some operational problems ... i.e. operators apparently were randomly selecting tapes to be mounted as "scratch" ... and i lost stuff that had been replicated on three different sets of tapes. a few past refs:
https://www.garlic.com/~lynn/2000.html#43 Historically important UNIX or computer things.....
https://www.garlic.com/~lynn/2000.html#44 Historically important UNIX or computer things.....
https://www.garlic.com/~lynn/2003j.html#14 A Dark Day
https://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2006w.html#42 vmshare

Drums: Memory or Peripheral?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Drums: Memory or Peripheral?
Newsgroups: alt.folklore.computers
Date: Sun, 03 Jun 2007 20:12:37 -0600
Quadibloc <jsavard@ecn.ab.ca> writes:
I did find another web site, and apparently the heads on the original FASTRAND could move; there was an array of heads, and moving them increased the number of possible tracks on the drum. (Of course, with conventional drums, there were several staggered rows of heads at different angular positions to allow the tracks to be closer together than the width of a head, so if the heads were all in only one row, this was a lower-performance type of drum.)

re:
https://www.garlic.com/~lynn/2007l.html#49 Drums: Memory or Peripheral?

... or possibly lower-capacity? modulo some factor.

the 2303 & 2301 were fixed head drums ... they appear to be physically the same with same total capacity. however 2301 had 1/4th the number of tracks, each one four times larger ... i.e. 2301 read/wrote 4 heads in parallel for four times the data transfer rate (of 2303)

2305-1 & 2305-2 were fixed head disks. they appear to be nearly physically the same ... with the same number of heads ... however 2305-1 had half the number of tracks and half the data capacity, but twice the data transfer rate and half the rotational delay ... aka two heads on each track, offset 180degrees, heads read/wrote in parallel on the same track. setup each track with half the track as odd bytes and the other half as even bytes ... offset heads read/wrote even/odd bytes and switched roles every half revolution.

thin-film floating heads lowered the flying height, increased the data density and reduced the inter-track spacing (for 3380 disk drives). i've posted before story about moving the air-bearing simulation (for design of thin-film floating heads) application off the 370/195 in bldg. 28 (sjr) to the newly installed 3033 in bldg. 15 (product test lab).

then there is this old email referencing the 16+2 proposal (wide thin-film head that could read/write 18 closely spaced tracks, by person responsible for 801/risc)
https://www.garlic.com/~lynn/2006s.html#email871230
in this post
https://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?

other old email in the same post, discussing 3380 inter-track spacing in original 3380s and "double density" 3380s
https://www.garlic.com/~lynn/2006s.html#email871122

more recent reference:
https://www.garlic.com/~lynn/2007k.html#21 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#38 John W. Backus, 82, Fortran developer, dies

misc. posts about getting to play disk engineer
https://www.garlic.com/~lynn/subtopic.html#disk

other posts in the thread from last fall
https://www.garlic.com/~lynn/2006s.html#23 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#31 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#33 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#45 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?

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

Drums: Memory or Peripheral?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Drums: Memory or Peripheral?
Newsgroups: alt.folklore.computers
Date: Sun, 03 Jun 2007 20:41:03 -0600
re:
https://www.garlic.com/~lynn/2007l.html#49 Drums: Memory or Peripheral?
https://www.garlic.com/~lynn/2007l.html#52 Drums: Memory or Peripheral?

for other topic drift ... somewhat related to 3380, thin-film, floating heads, etc. ... a couple recent posts mentioning los gatos vlsi lab
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-base
https://www.garlic.com/~lynn/2007l.html#47 My Dream PC -- Chip-base

one of the first chips that los gatos used electron microscope on was blue iliad ... first 32-bit 801 chip ... which never shipped in product.

los gatos lab also did jib-prime ... which was the microprocessor used in the 3880 disk controller.

los gatos also did the LSM (los gatos state machine, but written up in external documentation as the logic simulation machine). it was rated at doing chip design logic simulation at something like 50,000 times faster than 3033 processor. one of the things that set the LSM apart from the later machines (like EVE ... endicott verification engine) was provisions for timing (i.e. later machines would assume a synchronous clock) ... allowing it to handle chips with asynchronous clocks and digital chips with analog circuits (things like new generation of disk heads).

besides being allowed to play disk engineer in bldgs 14&15 ... i was allowed to play with chip grp in bldg 29 (los gatos lab) ... they let me have a couple labs and a suite of offices.

I also did some stuff in implementation of a new/different kind of experimental database ... being done somewhat as joint project between the VLSI tools grp in bldg. 29 and some of the people in STL (bldg. 90, now called silicon valley lab) ... at the same time I was doing some of the stuff for system/r in research ... some past mention of original relational/sql
https://www.garlic.com/~lynn/submain.html#systemr

misc. past posts mentioning LSM
https://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
https://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
https://www.garlic.com/~lynn/2002g.html#77 Pipelining in the past
https://www.garlic.com/~lynn/2002g.html#82 Future architecture
https://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
https://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
https://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD -
https://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
https://www.garlic.com/~lynn/2006q.html#42 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2007f.html#73 Is computer history taught now?
https://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings

Newbie question on table design

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Newbie question on table design.
Newsgroups: alt.folklore.computers
Date: Mon, 04 Jun 2007 06:49:19 -0600
Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
PPoE wanted cheaper MVS rates than major US corporate datacentres offered, negotiated same with UK corporate datacentre, but also wanted similar VMS connectivity for some reason, and had problems with thruput and various bandwidth sharing methods, so setup trunked dual 128Kbps TCP/IP links between datacentres, and tunnelled SNA over TCP/IP, getting over 90% SNA bandwidth after some consultation down south, patching TCP/IP and tweaking TCP/IP and SNA link parameters.

thread reference (x-over from comp.database.theory)
https://www.garlic.com/~lynn/2007j.html#2 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#7 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#8 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#9 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#11 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#12 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#14 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#16 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#17 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#24 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#39 Newbie question on table design

some other perspectives ... from nsfnet series of old email
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

that after they got us out of the way ... then some thot the way was clear to push sna/vtam into nsfnet
https://www.garlic.com/~lynn/2006w.html#email870109
in this post
https://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET
for other drift, recent reference
https://www.garlic.com/~lynn/2007l.html#14 Superconductors and computing

the original mainframe tcp/ip product had been implemented in vs/pascal (for vm/cms). for whatever reasons it had rather high overhead ... getting about 44kbytes/sec aggregate thruput using approx. full 3090 processor. i then added rfc 1040 support and in some testing at cray research ... was able to get 1mbyte/sec aggregate thruput (hardware limit) between a cray and 4341-clone (about factor of 500 times improvement in terms of byte transferred per instruction executed).
https://www.garlic.com/~lynn/subnetwork.html#1044

it was also eventually ported to mvs by providing a "diagnose" (i.e. vm kernel api) emulator in mvs

for other drift ... old folklore later about tcp support eventually being added to vtam:
https://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
https://www.garlic.com/~lynn/2005r.html#2 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006l.html#53 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgments
https://www.garlic.com/~lynn/2006w.html#29 Descriptive term for reentrant program that nonetheless is

for even more drift ... mainframe pascal had originally been done at los gatos lab ... by the vlsi tools group and used for a lot of different applications ... including a number of vlsi chip design applications and experimental database implementation ... recent los gatos lab references
https://www.garlic.com/~lynn/2007l.html#49 Drums: Memory or Peripheral?
https://www.garlic.com/~lynn/2007l.html#52 Drums: Memory or Peripheral?
https://www.garlic.com/~lynn/2007l.html#53 Drums: Memory or Peripheral?

other recent vs/pascal references
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007c.html#21 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007c.html#29 Being "Open" (Was: Mainframe vs. "Server")
https://www.garlic.com/~lynn/2007h.html#8 whiny question: Why won't z/OS support the HMC 3270 emulator
https://www.garlic.com/~lynn/2007h.html#41 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
https://www.garlic.com/~lynn/2007h.html#61 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
https://www.garlic.com/~lynn/2007j.html#14 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#16 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#70 Using rexx to send an email
https://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
https://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran developer, dies

Scholars needed to build a computer history bibliography

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scholars needed to build a computer history bibliography
Newsgroups: alt.folklore.computers
Date: Tue, 05 Jun 2007 09:05:54 -0600
Peter Flass <Peter_Flass@Yahoo.com> writes:
Somewhat special-purpose and not annotated, but you can use:
http://home.nycap.rr.com/pflass/plibib.htm as one potential source.


a little multics/pli x-over
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

from threads on prevalence of buffer overflows in C language programming environments
https://www.garlic.com/~lynn/subintegrity.html#overflow

some recent posts on the subject:
https://www.garlic.com/~lynn/2007g.html#49 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#14 conformance
https://www.garlic.com/~lynn/2007h.html#41 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings
https://www.garlic.com/~lynn/2007l.html#11 John W. Backus, 82, Fortran developer, dies

... for other drift ... multics (on the 5th flr of 545 tech sq) and the virtual machine operating system (cp40/cp67 at the sci center on the 4th flr of 545 tech sq) ... somewhat both grew out of mit's ctss project. old folklore can be found in melinda's
http://www.leeandmelindavarian.com/Melinda/
http://www.leeandmelindavarian.com/Melinda#VMHist
history paper that covers much of the period .. VM and the VM Community: Past, Present, and Future
http://www.leeandmelindavarian.com/Melinda/25paper.pdf

lots of posts mentioning sci center
https://www.garlic.com/~lynn/subtopic.html#545tech

Scholars needed to build a computer history bibliography

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scholars needed to build a computer history bibliography
Newsgroups: alt.folklore.computers
Date: Tue, 05 Jun 2007 09:32:10 -0600
re:
https://www.garlic.com/~lynn/2007l.html#50 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#51 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#55 Scholars needed to build a computer history bibliography

and for some relational/SQL DBMS ... there is
http://www.mcjones.org/System_R/index.html
and
http://www.mcjones.org/System_R/SQL_Reunion_95/

with lots of early remembrance ... not just system/r ... but a lot of DBMS activity going on in the period, some of the people, things like data base machines, etc. Nearly all of the System/R had also been done on virtual machine operating system implementation.

misc. past posts mentioning system/r
https://www.garlic.com/~lynn/submain.html#systemr

some recent postings with old email from some of the period:
https://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing

How would a relational operating system look like?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How would a relational operating system look like?
Newsgroups: comp.databases.theory
Date: Tue, 05 Jun 2007 11:21:18 -0600
Thomas Gagne <tgagne@wide-open-west.com> writes:
See what you can find out about the Teradata DBC/1012 database computer. It's operating system and relational engine were combined so that the two were indistinguishable. From what I found Googling around they no longer ship systems with their proprietary OS.

for other background ... system/r ... and for some relational/SQL DBMS ... there is
http://www.mcjones.org/System_R/index.html
and
http://www.mcjones.org/System_R/SQL_Reunion_95/

the reunion mentiond some of the "database machines" and the people involved. my impression from the period was that the inception of sybase (at least partially) involved moving off proprietary hardware and building on "more" COTS platforms

teradata specific reference:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Teradata.html#Index447

note that AT&T has since spun off NCR and NCR has announced spinning off Teradata.
http://www.teradata.com/updates

misc past posts mentioning relational, sql, system/r
https://www.garlic.com/~lynn/submain.html#systemr

for total other archeological drift ... in the system/r timeframe, Luther Woodrum was doing some amount on index structures ... both on disk and in memory. some of that eventually showed up in mainframe instructions supporting "in-memory" index structures (written up for sorting)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7

Scholars needed to build a computer history bibliography

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scholars needed to build a computer history bibliography
Newsgroups: alt.folklore.computers
Date: Tue, 05 Jun 2007 11:41:20 -0600
Joe Walker <joeNOSPAM@joewalker.org> writes:
Thanks very much, Peter. This list should give me somewhere to start looking into PL/I culture.

re:
https://www.garlic.com/~lynn/2007l.html#50 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#51 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#55 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#56 Scholars needed to build a computer history bibliography

slightly different language x-over ... multics was on the 5th flr of 545 tech sq., the (ibm) cambridge science center was on the 4th flr of 545 tech sq., and the (ibm) boston programming center was on the 3rd flr of 545 tech sq. ... misc. past posts mentioning 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech

rochester, sammet (and some number of other people) were on the 3rd flr at the boston programming center. as cp67 effort grew and morphed into vm370, the dev. effort took over the boston programming center (on the 3rd flr) and absorbed most of the (ibm) people on the 3rd into the vm370 product effort (before outgrowing 3rd flr, tech sq and moving out to the old SBC bldg. in burlington mall) ... with some others joining the science center (i.e. the vm370 development grp and the science center had split into two separate organizations by that time)

wiki reference mentioning Nat Rochester
https://en.wikipedia.org/wiki/Timeline_of_programming_languages
and reference here in article about the 701 team
http://www-03.ibm.com/ibm/history/exhibits/701/701_team.html
and a rochester "audio"
http://www-03.ibm.com/ibm/history/exhibits/701/audio/rochester_enh.wav

and wiki reference mentioning Jean Sammet
https://en.wikipedia.org/wiki/Jean_E._Sammet

a few past posts mentioning nat rochester, jean sammet and/or some of the other people at the boston programming center.
https://www.garlic.com/~lynn/2000d.html#37 S/360 development burnout?
https://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001m.html#47 TSS/360
https://www.garlic.com/~lynn/2002h.html#59 history of CMS
https://www.garlic.com/~lynn/2002j.html#17 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002o.html#76 (old) list of (old) books
https://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
https://www.garlic.com/~lynn/2003c.html#0 Wanted: Weird Programming Language
https://www.garlic.com/~lynn/2003c.html#1 Wanted: Weird Programming Language
https://www.garlic.com/~lynn/2003k.html#55 S/360 IPL from 7 track tape
https://www.garlic.com/~lynn/2004.html#20 BASIC Language History?
https://www.garlic.com/~lynn/2004b.html#14 The BASIC Variations
https://www.garlic.com/~lynn/2004d.html#42 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004m.html#54 Shipwrecks
https://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005k.html#44 Book on computer architecture for beginners
https://www.garlic.com/~lynn/2006j.html#44 virtual memory
https://www.garlic.com/~lynn/2006m.html#21 The very first text editor
https://www.garlic.com/~lynn/2006m.html#28 Mainframe Limericks
https://www.garlic.com/~lynn/2006s.html#1 Info on Compiler System 1 (Univac, Navy)?

Scholars needed to build a computer history bibliography

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scholars needed to build a computer history bibliography
Newsgroups: alt.folklore.computers
Date: Tue, 05 Jun 2007 12:59:11 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
wiki reference mentioning Nat Rochester
https://en.wikipedia.org/wiki/Timeline_of_programming_languages


re:
https://www.garlic.com/~lynn/2007l.html#50 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#51 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#55 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#56 Scholars needed to build a computer history bibliography
https://www.garlic.com/~lynn/2007l.html#58 Scholars needed to build a computer history bibliography

above wiki programming language timeline reference mentions apl ... so for a little more x-over ... the (ibm) phili science center had apl\360, the camb. science center took apl\360 and ported it to cp67/cms ... along the way could eliminate the embedded (apl\360) scheduler, dispatcher, swapper, terminal handler, etc ... which were needed to compensate for the primitive interactive facilities in the base os/360 platform (i.e. for cms\apl, features all provided by cp67). In addition, the storage allocation and storage garbage collection had to be redone as part of moving from the (apl\360) small, real-storage, apl workspaces, to the (relatively 10-100 times) large virtual memory workspaces available with cp67/cms.

lots of past posts mentioning HONE &/or APL ... i.e. HONE was an internal, online, interactive (initially cp67, later moving to vm370) service supporting world-wide sales, marketing, and field personal where majority of the applications were written in apl (initially cms\apl, but morphing thru the generations of apl\cms, apl\sv, vs\apl, etc).
https://www.garlic.com/~lynn/subtopic.html#hone

misc recent posts mentioning cms\apl
https://www.garlic.com/~lynn/2007b.html#32 IBMLink 2000 Finding ESO levels
https://www.garlic.com/~lynn/2007d.html#64 Is computer history taugh now?
https://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging
https://www.garlic.com/~lynn/2007g.html#39 Wylbur and Paging
https://www.garlic.com/~lynn/2007g.html#43 Wylbur and CRBE
https://www.garlic.com/~lynn/2007g.html#48 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#62 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#77 Sizing CPU
https://www.garlic.com/~lynn/2007j.html#13 Interrupts
https://www.garlic.com/~lynn/2007j.html#17 Newbie question on table design
https://www.garlic.com/~lynn/2007j.html#19 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate
https://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language?
https://www.garlic.com/~lynn/2007k.html#67 Non-Standard Mainframe Language?
https://www.garlic.com/~lynn/2007k.html#73 Non-Standard Mainframe Language?

Is Parallel Programming Just Too Hard?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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, 06 Jun 2007 08:16:59 -0600
a couple recent items:

The death of single threaded development
http://blogs.zdnet.com/Ou/?p=519
Google Acquires Multicore Programming Startup PeakStream -- Multithreaded Programming
http://www.informationweek.com/news/showArticle.jhtml?articleID=201001607
Intel updates compilers for multicore era
http://arstechnica.com/news.ars/post/20070605-intel-updates-compilers-for-multicore-era.html
Sun Updates Studio For Multi-core Development
http://itmanagement.earthweb.com/entdev/article.php/3681151
Sun stresses multicore chips, Linux with dev tool
http://news.yahoo.com/s/infoworld/20070604/tc_infoworld/89028
Scots firm demonstrates parallelizing compiler at MPF
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=199700792

recent posts on the subject:
https://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007g.html#3 University rank of Computer Architecture
https://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
https://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#24 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#26 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#34 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#38 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#42 My Dream PC -- Chip-Based

John W. Backus, 82, Fortran developer, dies

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: John W. Backus, 82, Fortran developer, dies
Newsgroups: alt.folklore.computers
Date: Wed, 06 Jun 2007 13:23:30 -0600
Peter Flass <Peter_Flass@Yahoo.com> writes:
I don't know about other systems, but OS/2 pages in executable programs and DLLs directly from where they're stored on disk. This was a big speedup; IIRC version 2 used to load them entirely and page them out to the swap file before starting, like other VM systems I'm familiar with. At some point, maybe version 4, they stopped doing this, since the program code was never modified during execution.

for a little drift ... after initial os2 ship ... they were looking on help with various operating system design issues ... and the endicott vm development group routed them to me ... recent posting of old emails
https://www.garlic.com/~lynn/2007i.html#email871204
https://www.garlic.com/~lynn/2007i.html#email871204b
in this post
https://www.garlic.com/~lynn/2007i.html#60 John W. Backus, 82, Fortran developer, dies

when i did the cms page mapped file system on cp67 ... there was some extra status bits available and i could play more games with in this area ... but in the morph from cp67 to vm370 they used up available status bits in the available status byte.
https://www.garlic.com/~lynn/submain.html#mmap

so i had to play some other kinds of status management.

in transition from mainframes to more personal computers ... the variety of "DASD" devices were reduced ... so there was possibly little or no discrepancy between the "best" paging device and the "worst" filesystem device.

early on i had done additional stuff in cp67 about moving "active" pages "UP" (from slower speed devices to higher speed devices) ... but it wasn't until the resource manager that I shipped code in the product that would also do the reverse (move less active pages from higher speed devices to slower speed devices) ... as well as better quantify what was met by "higher/better" and "slower/worse".

while the cms page mapped file system support didn't ship in standard product (outside lots of internal installations), i did ship it in the xt/370 & at/370 in the early to mid 80s ... where frequently the same (PC) harddisk was used for all activity (cms filesystem, cp paging, etc) ... over time there is less and less possible benefit from moving unmodified executable pages from one location to another location on disk.

also as relative sizes of real memory started to significantly increase ... compared to available disk space ... sometimes the alternative between "duplicate" and "no-duplicate" stategies could be come significant (i.e. reducing amount of disk space taken up by replicas of the same data).

misc. past posts mentioning "page migration"
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
https://www.garlic.com/~lynn/95.html#12 slot chaining
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
https://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003p.html#46 comp.arch classic: the 10-bit byte
https://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism
https://www.garlic.com/~lynn/2005n.html#21 Code density and performance?
https://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006i.html#24 Virtual memory implementation in S/370
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
https://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger?
https://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller chache

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

misc. past posts mentioning dup/duplicate vis-a-vis no-dup/no-duplicate allocation strategies
https://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
https://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
https://www.garlic.com/~lynn/2001l.html#55 mainframe question
https://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
https://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
https://www.garlic.com/~lynn/2002f.html#20 Blade architectures
https://www.garlic.com/~lynn/2002f.html#26 Blade architectures
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
https://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
https://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
https://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
https://www.garlic.com/~lynn/2006f.html#18 how much swap size did you take?
https://www.garlic.com/~lynn/2006i.html#41 virtual memory
https://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
https://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller chache
https://www.garlic.com/~lynn/2007e.html#60 FBA rant

Friday musings on the future of 3270 applications

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Friday musings on the future of 3270 applications
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 06 Jun 2007 22:21:24 -0600
patrick.okeefe@WAMU.NET (Patrick O'Keefe) writes:
At times like this I sorely miss my long lost APPN "Formats and Protocols" bible. I believe official sources claim that an APPN CP and an LU were different kinds of NAUs because they were different chunks of code. (Or at least the same chunk of code implementing 2 different FSMs.)

re:
https://www.garlic.com/~lynn/2007l.html#37 Friday musings on the future of 3270 applications

As undergraduate at the univ, I had done TTY/ascii terminal support for cp67 ... and attempted to make the 2702 do something that it couldn't quite do. that somewhat prompted a univ. project to build our own clone controller (originally using an Interdata/3). This was subsequently a writeup ... blaming us (at least in part) for clone controller business (interdata was subsequently bought by perkin-elmer and the box was sold under PE logo well thru the 80s ... apparently with the same channel interface card that was designed at the univ. in the 60s)
https://www.garlic.com/~lynn/submain.html#360pcm

the clone controller business was supposedly a major motivation behind the future system project
https://www.garlic.com/~lynn/submain.html#futuresys

... recent FS reference/post (with some quotation by one of the executives involved in FS)
https://www.garlic.com/~lynn/2007l.html#10 John W. Backus, 82, Fortran developer, dies

one might claim that when FS was killed, that SNA attempted to still meet some of the FS objectives with the PU4/PU5 interface for advanced terminal control infrastructure.

in the same time that SNA was starting, my wife co-authored peer-to-peer networking (AWP39) ... that defined real networking ... rather than complex terminal control. Possibly there was some amount of semantic confusion lingered on because the term "SNA" contained the word "network". Later, when my wife was con'ed into going to POK to be in charge of loosely-coupled architecture, she created peer-coupled shared data architecture (... and except for IMS hot-standby, didn't see a lot of uptake until sysplex)
https://www.garlic.com/~lynn/submain.html#shareddata

she had lots of battles with the SNA organization over peer-coupled shared data ... eventually there was temporary truce with my wife being able to specify Peer-Coupled operation as long as it was within the walls of the same/single machine room (datacenter) ... but SNA was mandated if it "crossed" the walls of the machine room.

much later, APPN was specified in AWP164 and when there was an attempt to announce/release APPN, the SNA organization non-concurred (at the time, the person responsible for APPN and I reported to the same executive). The APPN announcement was escalated and eventually the announcement letter was carefully rewritten to not imply that APPN had any relationship at all to SNA.

misc. past posts mentioning AWP39 and/or AWP164:
https://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
https://www.garlic.com/~lynn/2004p.html#31 IBM 3705 and UC.5
https://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
https://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005u.html#23 Channel Distances
https://www.garlic.com/~lynn/2006h.html#52 Need Help defining an AS400 with an IP address to the mainframe
https://www.garlic.com/~lynn/2006j.html#31 virtual memory
https://www.garlic.com/~lynn/2006k.html#9 Arpa address
https://www.garlic.com/~lynn/2006k.html#21 Sending CONSOLE/SYSLOG To Off-Mainframe Server
https://www.garlic.com/~lynn/2006l.html#4 Google Architecture
https://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
https://www.garlic.com/~lynn/2006o.html#62 Greatest Software, System R
https://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006r.html#9 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006u.html#28 Assembler question
https://www.garlic.com/~lynn/2006u.html#55 What's a mainframe?
https://www.garlic.com/~lynn/2007b.html#9 Mainframe vs. "Server" (Was Just another example of mainframe
https://www.garlic.com/~lynn/2007b.html#48 6400 impact printer
https://www.garlic.com/~lynn/2007b.html#49 6400 impact printer
https://www.garlic.com/~lynn/2007d.html#55 Is computer history taugh now?
https://www.garlic.com/~lynn/2007h.html#35 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#39 sizeof() was: The Perfect Computer - 36 bits?

Is Parallel Programming Just Too Hard?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Parallel Programming Just Too Hard?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
To: <ibm-main@bama.ua.edu>
Date: Thu, 07 Jun 2007 08:01:48 -0600
ibm-main@ibm-main.lst (Shane) writes:
Mmmmm - seems to be just a "warming over" of the multi-programming versus parallel discussion. With the exception of that last link, I'd need serious convincing any of them are "parallel programming".

I suspect in the not too distant future, "multi-threaded" will supplant (in the common vernacular) all notions of "parallel".

If not already ...


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

multi-threaded tends to be used in conjunction with tightly-coupled, shared-memory multiprocessing (and the current buzzword "multi-core"). lots of past posts mentioning shared-memory multiprocessing and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp

compare&swap instruction had been invented by Charlie (CAS are Charlie's initials) at the science center ... working on fine-grain multiprocessor locking for cp67
https://www.garlic.com/~lynn/subtopic.html#545tech

in order to get the instruction justified for 370, had to come up with the description of its use in multi-threaded/multi-programming operation, which was included (originally) in the (370) principles of operation ... a more recent version
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320

parallel has been used in reference to both (tightly-coupled) multi-threaded operation, as well as loosely-coupled &/or cluster multiprocessing operation

misc. past posts mentioning doing high availability, cluster multiprocessing product
https://www.garlic.com/~lynn/subtopic.html#hacmp

some old email references about working on cluster scale-up
https://www.garlic.com/~lynn/lhwemail.html#medusa

a couple old posts specifically about working on applying distributed lock manager and cluster scale-up to parallel oracle
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15

recent post mentioning my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture
https://www.garlic.com/~lynn/2007l.html#62 Friday musings on the future of 3270 applications

a lot of the "blades" stuff has been physical packaging originally done for (numerical intensive cluster) "GRIDs" (getting more & more computing into smaller and smaller footprint). some amount of GRID/blades are now being pitched into commercial sector. some of it isn't strictly loosely-coupled/cluster operation ... but it is also being used (frequently in combination with virtualization) for server consolidation.

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: Thu, 07 Jun 2007 15:10:35 -0600
blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
I've always wondered about that .... What's the point of asking for the user's *own* password? I mean, hasn't that already been supplied? Is this just a way of reminding people "hey, you're about to do something that might be risky?"

Or am I just clinging, for no particularly good reason, to the idea that root access should only be permitted to those who know the Super Secret (Root) Password? Presumably anyone trustworthy enough to be given the root password is also smart enough to choose a hard-to-guess personal password too ....


one of the movements in authentication is that the verification needs to be with regard to the individual/identity ... supplying the root password can be considered not providing the actual authentication related to the individual (and basically overiding some fundamental authentication/authorization principles). so one of the principles is that "root" password would nominally represent a "shared" password (aka possibly known by multiple people) used for overiding/bypassing individual authentication process.

It becomes somewhat less meaningful in the context of a personal computer (when theoretically there is only a single individual).

another argument has to do with privilege escalation concept ... where doing more privileged operations requires re-authentication for each such operation (over and above initial individual authentication for session involving basic system access). part of countermeasure to privilege escalation (as used in attacker attempting to compromise a system) will involve multiple stages of privileges and/or compartmentalization (not necessarily strictly hierarchical).

for a little topic drift ... recent discussion trying to differentiate authentication, authorization, identification, and identity
https://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as debate topic

and plug for our merged security taxonomy and glossary (recently prompting to update identity concepts) ... see authentication, authorization, and identity in the initial "concepts" section
https://www.garlic.com/~lynn/index.html#glosnote

mainframe = superserver

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe = superserver
Newsgroups: bit.listserv.ibm-main
Date: Thu, 07 Jun 2007 17:15:30 -0600
jackadama writes:
I realize that this has probably been asked before, but google didn't give me an answer. Before I asked my question let me state that I know that windows server 2003 and longhorn won't run on an IBM mainframe. There is the endian issue and the ascii vs ebcidic issues. Is there a medium to large IBM box that can run a couple hundred of virtual windows 2003 servers? And said box can scale up to approximately 1000+ virtual windows servers? Given that all current servers are dell and hp servers with 2 intel core 2 duo processors and a total of 150TB of storage?

I am doing research for the possible replacement of 200+ windows server in our datacenter. We need to add servers, but there is literally no more power. My thinking is if IBM can get windows servers to run on their something like their mainframes it would save electricity and space. Everyone would win.


recent cross-over from another thread:
https://www.garlic.com/~lynn/2007l.html#63 Is Parallel Programming Just Too Hard?

mentioning that blades are also being sold into commercial market, frequently in combination with virtualization, for server consolidation

and another mention here ... in slightly older thread/post:
https://www.garlic.com/~lynn/2007h.html#2 The Mainframe in 10 Years

and mention in this thread
https://www.garlic.com/~lynn/2007k.html#22 Another "migration" from the mainframe
https://www.garlic.com/~lynn/2007k.html#23 Another "migration" from the mainframe

some references from above thread

CIO Challenge: Energy Efficiency
http://www.wallstreetandtech.com/showArticle.jhtml?articleID=192202377
IBM Unveils New Energy-Efficient Blades
http://www.hpcwire.com/hpc/1379801.html
IBM to focus on energy efficiency
http://www.bladewatch.com/2007/05/10/ibm-to-focus-on-energy-efficiency/
Blade innovations highlight energy efficiency opportunities
http://www.it-director.com/business/content.php?cid=9135
IBM defends blades' energy efficiency
http://green.itweek.co.uk/2006/10/ibm_defends_bla.html
IBM Data Center and Facilities Strategy Services - high density computing data center readiness assessment
http://www-935.ibm.com/services/us/index.wss/offering/its/a1025605
Lots of Blade Server articles
http://www.eweek.com/category2/0,1874,1658862,00.asp
IBM Grid Computing Solutions - financial industry
http://www-03.ibm.com/grid/solutions/by_industry/financial.shtml
Grid Computing for Financial Services 2007
http://www.iqpc.com/cgi-bin/templates/genevent.html?topic=233&event=12603&
Grid computing: Accelerating the search for revenue and profit for financial markets
http://www-03.ibm.com/industries/financialservices/doc/content/landing/973028103.html

the previously mentioned scale-up activity was in large part about physical packaging and issues like power and cooling
https://www.garlic.com/~lynn/lhwemail.html#medusa

but the server consolidation is now frequently blades/grid technology in combination with virtualization .... curtesy of science center from mid-60s, first with cp40 and then when 360/67 became available, morphed into cp67 (precursor to vm370) ... misc past posts mentioning science center
https://www.garlic.com/~lynn/subtopic.html#545tech

besides virtualization and virtual machines being invented at the science center ... compare&swap instruction for multi-thread/multi-processor was also invented at the science center
https://www.garlic.com/~lynn/subtopic.html#smp

and also GML (later morphed into sgml, html, xml, etc)
https://www.garlic.com/~lynn/submain.html#sgml

and most of the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

which was also seen outside in deployments like bitnet and earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet

BAH's Point of View

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: BAH's Point of View
Newsgroups: alt.folklore.computers
Date: Fri, 08 Jun 2007 01:08:39 -0600
bv@wjv.com (Bill Vermillion) writes:
I've had a copy of that since 1977.

When asked to make a prediction about the future of home computing, and it's advancements, Ted said something along the lines of 'you can't predict it'.

The he proceeded to make predictions of the next XX years, and he was the most accurate of all those who made such pronouncements.

I also have an original copy of his Literary Machines - where he coined the word 'hypertext'.

I really like his writing.


more recent reference:
http://www.xanadu.net/

some past posts with similar references
https://www.garlic.com/~lynn/2000g.html#26 Who Owns the HyperLink?
https://www.garlic.com/~lynn/2002o.html#45 XML, AI, Cyc, psych, and literature
https://www.garlic.com/~lynn/2002o.html#47 XML, AI, Cyc, psych, and literature
https://www.garlic.com/~lynn/2003j.html#59 Ted Nelson, of Project Xanadu
https://www.garlic.com/~lynn/2005s.html#12 Flat Query

nouns and adjectives

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: nouns and adjectives
Newsgroups: alt.folklore.computers
Date: Sat, 09 Jun 2007 04:22:20 -0600
Morten Reistad <first@last.name> writes:
The Internet nearly fell apart into disconnected pieces because of politics in 1990. For a few months there were no universal end to end connectivity. Commercial ISP's were shunned, and lots of public contractors played silly games.

The ISPs united and played hardball, and formed the CIX. They got backing from high up. The CIX was the Commercial Internet Exchange. Almost all european connectivity was CIX-only for a while, so you had to choose; be academic and pure, or to have european connectivity.

CIX won out, and we got the commercial exchange-based Internet we have today. This model buried the NSFnet model from 1983.


... long post warning ...

the (academic) csnet, bitnet, earn, etc from early 80s was much more traditional networking of nodes. misc. posts mentioning bitnet/earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet

in fact (at least) csnet and bitnet predate the 1/1/83 transition to internetworking technology ... and the nsfnet backbone for operational support for internetworking of networks wasn't until late 80s. earn came after the 1/1/83 transition ... but was the bitnet expansion to europe ... post
https://www.garlic.com/~lynn/2001h.html#65
with old email from person setting up EARN
https://www.garlic.com/~lynn/2001h.html#email840320

NSFNET "backbone" in the late 80s was the operational basis for the modern internet ... i.e. tcp/ip was technology basis with support for "internetworking" ... i.e. interconnection of networks ... as opposed to just the more straight forward networking of nodes.

my ietf index has some references in the "archeological" section
https://www.garlic.com/~lynn/rfcietf.htm

also lots of past posts mentioning various aspects of NSFNET backbone
https://www.garlic.com/~lynn/subnetwork.html#nsfnet

and old email related to some of the stuff leading up to NSFNET backbone
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

as well as more general posts related to general internet
https://www.garlic.com/~lynn/subnetwork.html#internet

some of the stuff related to acceptable use policies of NSFNET backbone traffice was gov. funded, tax-free operation. however, there was a separate undercurrent of commercial interests. the commercial network & telco interests had significant amounts of unused capacity (including lots of "dark fiber" that had been going in all thru the 80s). They faced a significant chicken & egg situation ... they needed sufficient revenue flow to cover their fixed costs. Their revenue flow was based on usage charges. If they dropped their usage charges by a couple orders of magnitude to promote development of new, high bandwidth hungry applications, (to utilize the enormous unused capacity), there would be several yr transition period where income wouldn't cover their fixed costs (as the new high bandwidth applications evolved). So something like four times the NSF funded resources were contributed to NSFNET backbone (as paid for by NSF) by commercial interests (which presumably also came with tax write-off).

The result was that the commercial interests got something of a testbed incubator that would encourage the development of the new generation of bandwidth hungry applications ... but in a strictly limited environment w/o loosing a lot of their existing commercial revenue. Trying to grapple with this transition period was not a trivial thing ... trying to maintain sufficient revenue ... to cover very high fixed costs from a usage based fee paradigm ... while trying to transition to paradigm that would use a couple orders of magnitude more bandwidth (from 9.6k & 56k to 1.5m and higher). If you just cut all the fees per bit by two orders of magnitude, before the usage and bandwidth hungry applications had evolved ... the total revenue would drop by two orders of magnitude (at least for several yrs during transition period) ... which would be insufficient to cover fixed operating costs. However, w/o an environment where bandwidth was free or nearly free ... the new generation of bandwidth hungry applications wouldn't be likely to evolve.

The whole idea of commercial interests contributing significant resources to NSFNET backbone (on the order of four times the direct NSF funding) ... would be a non-permanent situation. As soon as the (NSFNET) "free" incubator had spawned the bandwidth hungry applications ... it would be possible for the commercial interests to start the transition of managing the usage price/bit transition to much higher bandwidth usage ... while still keeping total revenue such that it covered their high fixed operating costs.

Some of the somewhat unrelated silly stuff that went on in the late 80s and early 90s were some gov. mandates to eliminate the internet and move to OSI networking. The problem here was that OSI was a straight-forward networking of nodes paradigm from the 60s/70s. The whole idea behind the evolution of "internetworking" technology was the recognition that simple straight-forward networking paradigm wasn't going to be able to scale to spanning multiple networks and organizations. In that sense, the original arpanet and OSI were similar in being networking of nodes paradigm (aka any elimination of the internet and transition to OSI would have been reverything to the arpanet networking paradigm of the 70s ... aka lacking any technology or operational support for internetworking).

The 1/1/83 transition from arapnet networking technology to internetworking technology ... was the technology basis for the modern internet. It then required the NSFNET backbone to (also) evolve the operational issues supporting internetworking of networks. Then there was the transition in the early 90s evolving numerous of the business issues supporting internetworking of networks.

I would claim that the commercial interests in CIX weren't "battling" the NSFNET backbone ... since the NSFNET backbone had been so heavily subsidized/supported by the commercial interests. The transition from NSFNET backbone to commercial operation could be considered part of planned agenda from the start (but not something that the commercial interests had worked out how it was actually going to happen; kick it in motion and hopefully be able to ride out the turmoil).

One of the possible business issues ... was if the majority of the NSFNET backbone resources was contributed by commercial interests ... for which they got a tax writeoff, the tax writeoff might be compromized if it had commercial use. This was separate from the whole issue of providing the resources to NSFNET, and keeping it totally disjoint and separate ... so as to not impact their commercial revenue flow.

This is also separate from some of the other technology issues necessary for the operations of a (NSFNET) backbone for interneworking networks ... we were heavily involved in backbone operations ... both deployed technology on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

and dealing with many of the organizations that would become NSFNET backbone participants. however, along the way, we got involved in some internal politics and were prevented from bidding NSFNET backbone ... even tho we had heavy backing/lobbying from NSF and at one point an NSF audit that claimed what we already had running was at least five yrs ahead of all NSFNET backbone bids (to build something new). recent post with lots of topic drift
https://www.garlic.com/~lynn/2007l.html#14 Superconductors and computing

and other posts including old email specifically on the topic
https://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006w.html#43 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)
https://www.garlic.com/~lynn/2007d.html#47 Is computer history taugh now?

for other topic drift ... the above referenced "EARN" email from 84 was also inquiring about "computer conferencing". I had (also) been doing some semi-automated stuff starting in the late 70s. There was a period in the early 80s that it came to the attention of top corporate executives that such stuff might be going on over the internal network ... and I somewhat got blameed for it. There was something of turmoil during this period about how to treat this emerging new phenomena. One of the results (again more topic drift) was that a researcher was paid to study how I communicated ... they sat in the back of my office for something like nine months and took notes on my conversations, and also got logs of all my instant messages and copies of all my incoming and outgoing email. Besides an internal research report ... the study was also the basis for a stanford phd thesis and some number of papers and books. some collected posts on computer conferencing ... with some discussion of the subject
https://www.garlic.com/~lynn/subnetwork.html#cmc

nouns and adjectives

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: nouns and adjectives
Newsgroups: alt.folklore.computers
Date: Sat, 09 Jun 2007 04:41:07 -0600
re:
https://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives

for other topic drift ... we were called in to consult with a small client/server startup that wanted to do payment operations on their server ... a couple references
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

they had this technology called SSL and were working on this thing called a commerce server ... it is all now frequently referred to as electronic commerce. this thing called a payment gateway was developed and deployed
https://www.garlic.com/~lynn/subnetwork.html#gateway

which we periodically (also) claim to be the original "SOA".

it turns out that two of the people running the commerce server effort, we had previously worked with on our ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp

and were present at this meeting mentioned in these posts
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15

now the entity to deploy the first commerce server and also provided funding for a significant portion (possibly all?) of the commerce server development effort ... was also one of the major backers and resource contributors to the NSFNET backbone effort.
https://www.garlic.com/~lynn/subnetwork.html#nsfnet

aka they were (apparently) expecting that they would eventually benefit significantly more from the evolving bandwidth hungry applications ... than whatever they were providing in upfront funding.

nouns and adjectives

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: nouns and adjectives
Newsgroups: alt.folklore.computers
Date: Sat, 09 Jun 2007 05:34:06 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
This is also separate from some of the other technology issues necessary for the operations of a (NSFNET) backbone for interneworking networks ... we were heavily involved in backbone operations ... both deployed technology on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

and dealing with many of the organizations that would become NSFNET backbone participants. however, along the way, we got involved in some internal politics and were prevented from bidding NSFNET backbone ... even tho we had heavy backing/lobbying from NSF and at one point an NSF audit that claimed what we already had running was at least five yrs ahead of all NSFNET backbone bids (to build something new). recent post with lots of topic drift
https://www.garlic.com/~lynn/2007l.html#14 Superconductors and computing


re:
https://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#68 nouns and adjectives

in part because we had T1 & higher-speed support deployed, we like to think that all our work with the players in NSFNET backbone activity led to the NSFNET backbone RFP specifying T1 link (rather than some much smaller multiple of 56kbit).

We weren't allowed to bid ... however the winning bid didn't actually install T1 links ... what they installed for the NSFNET backbone was T1 circuits .. and then used IDNX multiplexers to split the bandwidth and actually deployed 440kbit links.

then for NSFNET-II (upgrade to T3), for whatever reason, we were asked to be the red team for one of the bid responses ... possibly believing the blue team, with a couple dozen people from half dozen labs around the world would thoroughly trounce us. At the review, I presented first and then the blue team presented. Before 10 mins into the blue team presentation, the executive running the process, got up, pounded on the table and declared that he would lie down in front of a garbage truck before he would allow any but the blue team proposal to go forward (apparently it was too readily apparent that the blue team had failed to trounce us). At that time, my wife and I got up and left the room (as well as a couple others) ... as it happens the blue team proposal was winning bid for NSFNET-II (and we had much better technology/operation than winning bids for both NSFNET-I and NSFNET-II).

misc. past posts mentioning garbage truck comment
https://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview
https://www.garlic.com/~lynn/2006e.html#38 The Pankian Metaphor
https://www.garlic.com/~lynn/2006u.html#56 Ranking of non-IBM mainframe builders?

other posts mentioning nsfnet
https://www.garlic.com/~lynn/subnetwork.html#nsfnet

nouns and adjectives

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: nouns and adjectives
Newsgroups: alt.folklore.computers
Date: Sat, 09 Jun 2007 06:09:55 -0600
re:
https://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#68 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#69 nouns and adjectives

for total different "noun" drift ... the word identity; a couple days ago, I got asked by one of the identity management players about upgrading my merged security taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote

with a lot more stuff related to identity and various identity activities. i also mentioned it in this recent long-winded post
https://www.garlic.com/~lynn/aadsm27.htm#23 identity resurges as a debate topic

so i plowed thru several sources and managed to integrate some stuff. part of the churn and swirl is that in the past, identity has been mostly associated with authentication ... and separate from authorization. a lot of the current churn appears to be around providing sufficient personal information that a relying party can make some sort of authorization decision (approve something, grant permissions, etc) about a total stranger.

something similar went on in the early 90s with x.509 identity certificates ... tending to grossly overload the identity certificates with lots of personal information ... so that a relying party might be able to make some autherization decision about a total stranger ... purely based on the contents of the certificate. this was straying from the more common use of identity as characteristic of authentication ... and moving way into the domain of authorization. (in addition to who are you, are you allowed/permitted to do something?)

part of the tension is also similar to events of the mid-90s when lots of parties started to realize that x.509 identity certificates, grossly overloaded with personal information, represented significant privacy and liability issues ... which then resulted into retrenching to relying-party-only certificates ... carrying little or no information
https://www.garlic.com/~lynn/subpubkey.html#rpo

i've tried to capture some of that sense (the difference in using identity with respect to authentication and authorization) in the additions to the merge security taxonomy and glossary ... see concepts section
https://www.garlic.com/~lynn/secure.htm

some recent news articles some of the identity churn

Computer Expert Urges identity Verification Safeguards for Employee Eligibility Systems
http://newswire.ascribe.org/cgi-bin/behold.pl?ascribeid=20070607.071237&tim
Who Are You? ID Purveyors to Collaborate
http://itmanagement.earthweb.com/article.php/3681961
Vendors Debate ID Protocols
http://www.pcworld.com/article/id,132613-c,unresolvedtechstandards/article.html
Who Are You? ID Purveyors to Collaborate
http://news.earthweb.com/security/article.php/3681941
Who Are You? ID Purveyors to Collaborate
http://www.internetnews.com/security/article.php/3681941
Who Are You? ID Purveyors to Collaborate
http://itmanagement.earthweb.com/secu/article.php/3681961
Vendors seek unity on identity protocols
http://newsvac.newsforge.com/newsvac/07/06/06/2011211.shtml
Vendors seek unity on identity protocols
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9023619
Vendors seek unity on identity protocols
http://www.infoworld.com/article/07/06/06/Vendors-seek-unity-on-identity-protocols_1.html
Vendors seek unity on identity protocols
http://www.networkworld.com/news/2007/070607-credit-card-thieves.html

IBM 360 Model 20 Questions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 Model 20 Questions
Newsgroups: alt.folklore.computers
Date: Sat, 09 Jun 2007 16:13:18 -0600
Quadibloc <jsavard@ecn.ab.ca> writes:
Basically, on the System/360, there were two "standard" calling sequences used by assembly-language programmers, the R-type (for register) used for simple subroutines, and the S-type (for storage) used for more elaborate subroutines.

basically coming out of the os/360 heritage of "small" real memories there was extensive use of pointer-passing convention. in the transition to current descendants of os/360 ... that involved adding virtual memory ... to minimize any discontinuity ... it required all the standard "called" routines to be in the same address space as the (calling) application. even with the transition from SVS to MVS ... where each application got its own address space ... the 370 limitation of 24bit (16mbyte) virtual address space got to the point where some installations only had 2-3mbytes left for an application to run in ... i.e. the rest of each 16mbyte virtual address space was occupied by standard librarcies, operating system services, kernel image, etc.

coming out of the cancellation of future system project:
https://www.garlic.com/~lynn/submain.html#futuresys

there was crash program to turn out "811" architecture ... the general architecture defined 31-bit virtual address support as well as "program call" and "access registers". however, such a crash program was still going to take nearly a decade ... and so 3033 was sort of an intermediate (370) stop-gap effort. they did manage to fit in dual-address space mode into 3033 (sort of a subset of the more general access register stuff).

dual-address space was somewhat for semi-privileged system services (some of the services are somewhat analogous to demons) that reside in their own virtual address space. applications call them with pointer passing paradigm ... the kernel does virtual address space switch ... and now the subsystem service is sitting with a passed pointer to data in the original applications virtual address space. dual-address space support allows the subsystem service to simultaneously access both its own virtual address space as well as the calling application's virtual address space.

the later, more general "access register" and "program call" support allowed for a hardware defined table where the program call resulted in controlled changing of the virtual address space pointers by the program call (and program return) instruction (w/o having to pass thru kernel code) ... as well as expanding the number of simultaneous, concurrent different virtual address spaces that could be addressed.

a few past posts mentioning dual-address space, access register, and/or program call
https://www.garlic.com/~lynn/2007g.html#39 Wylbur and Paging
https://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007k.html#14 Some IBM 3033 information
https://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation
https://www.garlic.com/~lynn/2007k.html#28 IBM 360 Model 20 Questions




previous, next, index - home