List of Archived Posts

2001 Newsgroup Postings (07/22 - 08/17)

PKI/Digital signature doesn't work

Alpha: an invitation to communicate

Alpha: an invitation to communicate

PKI/Digital signature doesn't work

PKI/Digital signature doesn't work

PKI/Digital signature doesn't work

PKI/Digital signature doesn't work

PKI/Digital signature doesn't work

VM: checking some myths.

VM: checking some myths.

VM: checking some myths.

checking some myths.

checking some myths.

VM: checking some myths.

Installing Fortran

IBM 9020 FAA/ATC Systems from 1960's

D

IBM 9020 FAA/ATC Systems from 1960's

checking some myths.

checking some myths.

physical vs. virtual addresses

checking some myths.

Intel's new GBE card?

Redhat 7.2?

"Hollerith" card code to EBCDIC conversion

earthlink timing out nntp connections

TECO Critique

TECO Critique

checking some myths.

checking some myths.

earthlink timing out nntp connections

earthlink timing out nntp connections

Wanted: pictures of green-screen text

D

D

D

PKI/Digital signature doesn't work

Credit Card # encryption

Credit Card # encryption

Credit Card # encryption

Credit Card # encryption

Credit Card # encryption

Credit Card # encryption

Credit Card # encryption

Wired News :The Grid: The Next-Gen Internet?

Article: Future Trends in Information Security

Whom Do Programmers Admire Now???

ummmmm

Whom Do Programmers Admire Now???

Other oddball IBM System 360's ?

Flip the bits in a byte

future of e-commerce

Flip the bits in a byte

Net banking, is it safe???

YKYGOW...

YKYGOW...

Blinkenlights

Whom Do Programmers Admire Now???

Net banking, is it safe???

Blinkenlights

Whom Do Programmers Admire Now???

Net banking, is it safe???

Net banking, is it safe???

Blinkenlights

Net banking, is it safe???

UUCP email

UUCP email

Would this type of credit card help online shopper to feel more secure?

Net banking, is it safe???

Very CISC Instuctions (Was: why the machine word size ...)

Net banking, is it safe???

IBM 9020 FAA/ATC Systems from 1960's

ummmmm

Most complex instructions

YKYGOW...

Net banking, is it safe???

Other oddball IBM System 360's ?

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Sun, 22 Jul 2001 13:30:29 GMT

"Harris Georgiou" writes:

Not really. The whole idea behind the digital certificate is possesion of
some piece of information unique to that person. Any digital certificate
contains a key pair (complete/owner form) or just the public part of it in
order to be used for verification by others. We often use the term
certificate only for the public part because that is what everybody else
uses to identify that person, but the complete for of it (available only to
the owner) is the whole key pair. relying-party-only certificates are not
mandatory to ensure the validity of a certificate. PGP keyservers keep all
keys in public access and everybody can grant or revoke his/hers expression
of trust towards any key by signing with the personal key. It is a
distributed service, thus more reliable than any centralized certificate
management.

as an aside, we had coined the term certificate manufacturing to try
and distinquish between many of the current environments and some of
the theoritical proposals involved in many PKI definitions (it has
since been picked up and used in some number of other references).

we had been involved in helping create something called "electronic
commerce" and had to do some amount of due diligence on some of the
entitites doing certificate manufacturing.

the talk I was at where somebody from the german banking community
gave a description & reasons for relying-party-only certificates was
at the following conference

http://csrc.nist.gov/nissc/1998/index.html

at the conference, I was on a PKI panel that included CTOs & the ilk
from several certificate manufacturing companies ... misc. ref:

http://www.garlic.com/~lynn/2001g.html#0

random refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aepay7.htm#nonrep6
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
http://www.garlic.com/~lynn/aadsm6.htm#echeck

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

Alpha: an invitation to communicate

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Alpha:  an invitation to communicate
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch
Date: Sun, 22 Jul 2001 16:54:25 GMT

Peter Hancock writes:

I though VM was the underlying thing, and MVS was one of the things
VM could host?

ISTM that its not at all improbable that sometime soon we will need or
have some kind of virtual machine technology that could allow all
kinds of bizarre software monstrosities to run in whatever kind of
crazy environment they want.  Is this a platitude?

it is possible that a lot more familiar with the resource management
and industrial strength features of MVS ... than are familiar with the
resource management and industrial strength features of VM.

random ref:
http://www.garlic.com/~lynn/subtopic.html#disk
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/subtopic.html#hacmp
http://www.garlic.com/~lynn/subtopic.html#360mcode

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

Alpha: an invitation to communicate

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Alpha:  an invitation to communicate
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch
Date: Mon, 23 Jul 2001 21:05:45 GMT

JF Mezei writes:

This was the "old way".  But MVS-only shops can run multiple instances of MVS
on a 390 or higher without the presence of VM. This saves a lot of overhead
since IO is not intercepted by VM.

I did hear that VMS was making a comeback to run multiple instances of Linux
on IBM mainframes though.

i think that if you look closely ... LPARS are essentially a whole lot
of VM moved into the "microcode" of the hardware with various
options/features simplified. it basically started out as hardware
accelerater for VM kernel (by incorporting significant performance
parts of vm kernel into the microcode of the hardware) ... and at some
point enuf of the VM kernel functions had been migrated to the
hardware of the machine that it was possible to provide a subset of
the VM kernel functions w/o even running the full-blown vm kernel.

if you look at the LPAR documentation with regard to performance
planning, there is still some amount of "vm" overhead still involved
(it just that it is somewhat less because it is being done in the
hardware w/o ..at least.. the overhead of a context switch into a
different address space & software processing).

a subset of the VM commands is still seen on the console for doing
LPAR configurations. Also, the hardware console/service processor may
or may not still be a VM system (aka all 3090s contained two
"embedded" 4361s running a modified version of vm/370 release 6 that
were the service processor and hardware console interface).

random refs:
http://www.garlic.com/~lynn/subtopic.html#360mcode

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

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Mon, 23 Jul 2001 00:48:54 GMT

"Harris Georgiou" writes:

I understand your point. The idea behind relying-only-party certificates is
in fact the combination of issuing the certificate, managment and real-time
update (status query), all by the same provider. It is surely a more
advanced and effective version of the typical PKI provider and it solves
many problems and ambiguities. It's just that in lack of general purpose PKI
services (except custom-made, say, for a banking application), the only
available scheme is the keyserver model implemented for PGP-like
applications.

furthermore, relying-party-only certificates are redundant and
superfluous.

actually certificates are redundant and superfluous in an online
model, where the "certification" check can be done via an online
query; it is just that it is quite a bit more obvious when the relying
party and the registration party are the same ... to be able to see
that the certificate is extraneous in the whole operation.

certificates were designed to serve a purpose in the offline world,
where it wasn't possible to directly contact the registration &
certification authority ... and so had to relying on a distributed
credential in place of an online query.

The r/o distributed credential (aka certificate) is otherwise
redundant, superfluous and extraneous if you can directly do an online
query.

An example is the current SSL server domain name certificates and
being able to achieve the same purpose in a much better way by having
the online domain name infrastructure provide real-time public key
distribution and certification .. aka instead of registering your
domain name and public key with a certification authority ... collapse
the whole thing into the domain name infrastructure and register a
public key at the same time the domain name is registered. the domain
name infrastructure than can provide real-time certification and
distribution of public key ... instead of the current mechanism
relying on stale manufactured certificates.

misc. ref:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

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

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Mon, 23 Jul 2001 20:46:41 GMT

those who know me have no need of my name <not-a-real-address@usa.net> writes:

for this to become a reality dnssec needs to be widely deployed, and the
server must be able to require that only secure delegations are followed.
i would not hold be breath.

but the "integrity chain" for SSL domain name certificates are
currently at risk w/o it; aka an entity requests a SSL domain name
certificate from a certification authority; the certification
authority has to certify that validity of the owner of that domain
name with the authoritative agency for domain names ... which is the
domain name infrastructure.

the interesting aspect is supposedly the justification for SSL domain
name certificates in the first place are integrity weaknesses in the
domain name infrastructure. so at least the Certification Authority
business of SSL domain name certificates have to improve the integrity
of the domain name infrastructure for their own purposes (in order
that they can rely on what it is that they are certifying ... so
people can rely on their certificates). however, if they improve the
integrity of the domain name infrastructure to meet minimum integrity
requirements for their own business; they also eliminate much of the
justification for SSL domain name certificates in the first place.

misc. ref:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

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

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Wed, 25 Jul 2001 12:17:36 GMT

"Harris Georgiou" writes:

Current e-shopping security is based on the integrity of each node from
which that sensitive data go through. Encryption may be used during
transmissions but credit card numbers are usually stored in an unecrypted
form. This is the real reason for the 2.000.000+ bogus transactions every
year with stolen numbers. Maybe this could be drastically limited if there
was some way the company could verify your side, you could verify theirs,
and none in the middle could keep a copy of the account or transaction.
There are many things that can be improved in current e-shopping policies.

the current CC implementation was done because it was relatively
straight-forward, much of the infrastructure was already in place, and
there was already support for business practices associated with
non-face-to-face (aka MOTO or mail-order/telephone-order)
transactions).

random refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

work then began in financial standards body for authentication
transactions in untrusted &/or insecure networks (aka debit & atm
cards already had PIN authenticated transactions that operated in
secure networks).

the result of that in the financial standards world was the X9.59
standard for all electronic account-based transactions (along with
some enhancements to ISO 8583 to carry X9.59 digital signature in the
payment card scenerio). Part of the X9.59 standards was that "x9.59"
related account numbers could only be used in authenticated
transactions (i.e. the harvesting of account numbers from x9.59
transactions could not later be used in fraudulent, unauthenticated
transactions; essentially removing such account numbers from the
status of shared-secret and points of exploit).

There already have been debit network pilots ... and work is underway
for production roll-outs.

misc. refs:
http://www.garlic.com/~lynn/nacharfi.htm
http://www.garlic.com/~lynn/99.html#224
http://www.garlic.com/~lynn/aadsmore.htm#nacha

mapping of x9.59 standard to iso 8583 payment network standard
http://www.garlic.com/~lynn/8583flow.htm

misc. other x9.59 references
http://www.garlic.com/~lynn/

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

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Wed, 25 Jul 2001 12:42:29 GMT

"Harris Georgiou" writes:

Most of them currently use simple SSL as an alternative. But ALL of them
provide the client-side software with a digital certificate that verifies
that the transaction actually involves the real bank and not some
eavesdropper (see SSL specification for complete description).

the digital certificates in SSL domain name server certificates are
supposedly justified on weaknesses in the domain name infrastructure.

so somebody goes to a certification authority (CA) to get a SSL domain
name server certificate. Since the Certification Authority has no
trusted database of who owns which domain name, the Certification
Authority goes to the authoritative agency for domain name ownership
(aka the domain name infrastructure) to verify that the entity really
owns the domain name. The CA then certifies (in a digital certificate)
that it has checked with the domain name infrastructure as to the true
owner of the domain name before issueing the SSL domain name server
certificate.

The client SSL code, when it receives a SSL domain name server
certificate, checks the domain name specified in the SSL domain name
server certificate against the URL that the client had used to contact
the server; if they "match" ... SSL proceeds (there are misc. other
things like checking to see that the CA signing the certificate is in
the built-in list of CAs).

The problem, of course, is that Certification Authorities have to rely
on the very same (insecure) domain name infrastructure as the final
authority/arbritrator for information that they certified ... this
same domain name infrastructure that the clients rely on for doing
domain name -> ip address resolution.

random ref:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

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

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: Wed, 25 Jul 2001 12:54:29 GMT

"Lyalc" writes:

Let's just think about passwords as an elelctronic signature mechanism
The only people who need to verify this initially at the oroginator, and the
recipient, both of whom are part of the existing relationship, and the only
entities who can verify the password in the first place.

Thus there is no compromise.

Later, if there is a need to re-verify, the relying party's records from
archives and backups (person x had this password at this time which is
affixed in encrypted form to that document) should suffice in court.

This is true of the encryption process used to bind the password to the
document.
Lyal

the problem is (at least) protecting the password/shared-secret files
at the recipient. there are frequent news reports about shared-secret
leakage as well as major shared-secret harvesting events at recipient
sites.

shared-secret has the same value originating and validating the
"electronic signature". leakage of shared-secrets (especially by
recipients) allows fradulant originated tranactions. easly seen in all
the reports about CC account# leakage & harvesting (since for all
intents and purposes in the current infrastructure ... the CC account
numbers are shared-secrets and can be used to origiante fradulent
transactions).

public/private key authentication technology upgrade to existing
shared-secret business processes is a relatively inexpensive upgrade
to eliminate major exploits.

random refs:
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/aadsm2.htm#inetpki A PKI for the Internet (was RE: Scale (and the SRV
http://www.garlic.com/~lynn/aadsm2.htm#account A different architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#keyl4 On leaving the 56-bit key length limitation
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm3.htm#cstech cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech2 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech10 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech13 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss3 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
http://www.garlic.com/~lynn/aadsm4.htm#00 Is The Public Key Infrastructure Outdated?
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki Simple PKI
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsmore.htm#keytext proposed key usage text
http://www.garlic.com/~lynn/aadsmore.htm#killer1 Killer PKI Applications
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aepay2.htm#privrule3 U.S. firms gird for privacy rules
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1 Domain Name integrity problem
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
http://www.garlic.com/~lynn/aepay6.htm#harvest harvesting of credit card numbers
http://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
http://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aepay6.htm#ecml Electronic Commerce Modeling Language
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
http://www.garlic.com/~lynn/ansiepay.htm#ifraud Internet Fraud
http://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#173 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#214 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#33 SmartCard with ECC crypto
http://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#47 TLS: What is the purpose of the client certificate request?
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000b.html#14 Will Radius be obsolute if implement 2-token authentications?
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000b.html#46 Simple authentication protocol: any good?
http://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
http://www.garlic.com/~lynn/2000b.html#90 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000c.html#32 Request for review of "secure" storage scheme
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
http://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card numbers safely
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#49 Use of SET?
http://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001c.html#9 Server authentication
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#65 Key Recovery System/Product
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#19 [Newbie] Authentication vs. Authorisation?
http://www.garlic.com/~lynn/2001d.html#20 What is PKI?
http://www.garlic.com/~lynn/2001d.html#21 What is PKI?
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#53 April Fools Day
http://www.garlic.com/~lynn/2001d.html#62 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#73 Rational basis for password policy?
http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001e.html#52 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#81 Passwords
http://www.garlic.com/~lynn/2001f.html#24 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001f.html#52 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#54 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#55 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001g.html#0 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#40 Self-Signed Certificate
http://www.garlic.com/~lynn/2001g.html#63 PKI/Digital signature doesn't work

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

VM: checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch
Date: Wed, 25 Jul 2001 22:16:45 GMT

hack@watson.ibm.com (hack) writes:

Historically, the coupling between virtual card punches and readers (across
the RSCS company-wide network, aka VNET) was the primary communication
interface (nearly 30 years old).  It may sound quaint, but it's really just
a data pipe (with 80-byte blocks) with tagged ends to perform the connection,
and it has a really simple interface (no connection protocols etc. -- the
network is store-and-forward, so it's literally like mailing postcards where
bunches (individual "spool files") are guaranteed to arrive in order (there
is no virtual equivalent to a deck of cards spilled on the floor).

VNET also supports "SMSG" & instant messaging.

There was a standard instant message between the terminals belonging
to two different virtual machines.q

On the same machine, the straight forward messages allowed instant
person-to-person communication/message. SMSG supported
programmatically interception of instant messages allowed various
automated infrastructure, automated operator, tape mounting services,
etc.

The support by VNET of SMSG allowed the "instant messaging" to be
expanded to the network environment (i.e. VNET had an immediate
message communication, separate from normal file & data ... which
would support this extending instant messaging to a multiple machine,
network environment).

instant messaging between two real people in two virtual machines
instant messaging between one real person and a program in two virtual machines
instant messaging between two programs in two virtual machines

instant messaging between one real person and VNET in two virtual machines
       ... with VNET acting as transport to different real machine
       ... where it is a real person at the other end

instant messaging between one real person and VNET in two virtual machines
       ... with VNET acting as transport to different real machine
       ... where it is a program at the other end

instant messaging between one program and VNET in two virtual machines
       ... with VNET acting as transport to different real machine
       ... where it is a program  at the other end

and of course, VNET could be used between two parties on the same
machine.

The summer of 1980, the author of REXX did a multi-palyer, distributed
spacewar implementation using the SMSG mechanism; on the same machine,
spacewar distributed messages directly ... and this could operate in a
multi (real) machine environment using VNET's support of instant
messaging.

Now the case was the spacewar game running in one virtual machine, was
it actually interacting with a real person ... or was it a program
simulating a real person.

random refs:
http://www.garlic.com/~lynn/2001f.html#10
http://www.garlic.com/~lynn/2001f.html#12
http://www.garlic.com/~lynn/2001f.html#14

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

VM: checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch
Date: Wed, 25 Jul 2001 23:45:48 GMT

Aaron Sawyer writes:

Sounds like Cambridge University's CP/CMS (Control Program/Cambridge Monitor
System) on the S360/67 (65 with DAT box, IIRC).  Certainly had the Virtual
Machine implemented.  Very nice.

[remainder snipped; nothing to add]

It was the IBM Cambridge Scientific Center located at 545 Tech. Sq.,
Cambridge Mass (same bldg. as Multics) and had some number of people
that worked on CTSS. Started with CP & CMS on 360/m40 that had custom
modified hardware to support virtual memory in '65/'66 era ... and
then was ported to 360/m67 when it became available.

misc. online history from Melinda Varian
http://www.princeton.edu/~melinda

  CSC had 30 or so people. It originated CP/40, CP/67, CMS, VNET, GML,
compare&swap, various performance tuning, early capacity planning
and misc. other things. compare&swap turns out to be the initials of
the primary person at CSC responsible. GML (which spawned the whole
genre of markup languages, SGML, HTML, XML, etc) is the letter of the
lastnames of three people involved (i.e. generalized markup language
was chosen to match their initials).

The internal "VNET" network was consistently larger than the
arpa/internet until about 1985. I claim one of the reasons is that
VNET essentially contained a "gateway" function allowing the
interconnection of networks ... the "internet" didn't really get that
capability until Jan. 1st, 1983. random refs:

http://www.garlic.com/~lynn/internet.htm

I was at a university on the west coast and some people came out and
installed CP/67 in January of 1968 (third CP/67 installation after CSC
and Lincoln Labs).

misc. following have some refs:
http://www.garlic.com/~lynn/subtopic.html#360pcm
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#360mcode
http://www.garlic.com/~lynn/subtopic.html#smp

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

VM: checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Thu, 26 Jul 2001 07:31:37 GMT

"mulp" writes:

IBM implemented virtula machines (VM's) before the above was implemented -
the upgrade strategy that IBM used to move customers to the 360 was to
provide VM's for each of the machines that IBM wanted to replace - eg.,
those 1401 somethings or another.  And there were probably other VM's as
well before the 360 from IBM and other vendors.

IBM provided hardware emulation of earlier hardware on various
processors ...  i.e. 360s were almost all microcoded machines
... where "microcode" on the microprocessor emulated 360. The machines
were also shipped with "microcode" to simulate other machines. The
following is out of a recent "golden era of compilers" thread in
alt.folklore.computers:

>40    1410 (I don't remember that it also did 1401)
          1410 or 1401 - 2 different products
>50    1410, maybe 7040
           1410 or 7070 (2 distinct products, you couldn't get both!)
>65    709x
           and IIRC also 705/7080

7070 includes 7074, and 1410 includes 7010.

aka 360/m40 had microcode emulation to emulate earlier machines. note
also that 360/m30 included microcode emulation for 1401. Typically,
there was a switch on the front panel someplace that switched between
360 hardware (emulation) and some other hardware emulation.

I don't know anybody claiming such implementations were virtual
machines.

note reference in [26} below in extract from melinda's paper at PUCC
http://www.princeton.edu/~melinda

C. CP-40 and CMS

In the Fall of 1964, the folks in Cambridge suddenly found themselves
in the position of having to cast about for something to do next. A
few months earlier, before Project MAC was lost to GE, they had been
expecting to be in the center of IBM's time-sharing activities. Now,
inside IBM, ``time-sharing'' meant TSS, and that was being developed
in New York State. However, Rasmussen was very dubious about the
prospects for TSS and knew that IBM must have a credible time-sharing
system for the S/360. He decided to go ahead with his plan to build a
time-sharing system, with Bob Creasy leading what became known as the
CP-40 Project.

The official objectives of the CP-40 Project were the following:

1. The development of means for obtaining data on the operational
characteristics of both systems and application programs;

2. The analysis of this data with a view toward more efficient machine
structures and programming techniques, particularly for use in
interactive systems;

3. The provision of a multiple-console computer system for the
Center's computing requirements; and

4. The investigation of the use of associative memories in the control
of multi-user systems.[22]

The project's real purpose was to build a time-sharing system, but the
other objectives were genuine, too, and they were always emphasized in
order to disguise the project's ``counter-strategic'' aspects.
Rasmussen consistently portrayed CP-40 as a research project to ``help
the troops in Poughkeepsie'' by studying the behavior of programs and
systems in a virtual memory environment. In fact, for some members of
the CP-40 team, this was the most interesting part of the project,
because they were concerned about the unknowns in the path IBM was
taking. TSS was to be a virtual memory system, but not much was really
known about virtual memory systems. Les Comeau has written: Since the
early time-sharing experiments used base and limit registers for
relocation, they had to roll in and roll out entire programs when
switching users....Virtual memory, with its paging technique, was
expected to reduce significantly the time spent waiting for an
exchange of user programs.

------------------------------------------------------------

31 or 32 bits. We eventually voted and recommended 31 bits. We also
discussed the design of the relocation register and had some heated
discussions with the IBM team. The Inner Six met with IBM
representatives behind closed doors at a SHARE meeting. We six sites
discussed various features of TSS and made recommendations to
IBM. This was the beginning of the SHARE TSS Project.'' (J.M. Winett,
private communication, 1990.)

22 R.J. Adair, R.U. Bayles, L.W. Comeau, and R.J. Creasy, A Virtual
Machine System for the 360/40, IBM Cambridge Scientific Center Report
320-2007, Cambridge, Mass., May, 1966.

------------------------------------------------------------

What was most significant was that the commitment to virtual memory
was backed with no successful experience. A system of that period that
had implemented virtual memory was the Ferranti Atlas computer, and
that was known not to be working well.  What was frightening is that
nobody who was setting this virtual memory direction at IBM knew why
Atlas didn't work.[23] Creasy and Comeau spent the last week of
1964[24] joyfully brainstorming the design of CP-40, a new kind of
operating system, a system that would provide not only virtual memory,
but also virtual machines.[25] They had seen that the cleanest way to
protect users from one another (and to preserve compatibility as the
new System/360 design evolved) was to use the System/360 Principles of
Operations manual to describe the user's interface to the Control
Program. Each user would have a complete System/360 virtual machine
(which at first was called a ``pseudo-machine'').[26] The idea of a
virtual machine system had been bruited about a bit before then, but
it had never really been implemented. The idea of a virtual S/360 was
new, but what was really important about their concept was that nobody
until then had seen how elegantly a virtual machine system could be
built, with really very minor hardware changes and not much software.

------------------------------------------------------------

23 L.W. Comeau, ``CP-40, the Origin of VM/370'', Proceedings of SEAS
AM82, September, 1982, p. 40.

24 Creasy had decided to build CP-40 while riding on the MTA. ``I
launched the effort between Xmas 1964 and year's end, after making the
decision while on an MTA bus from Arlington to Cambridge. It was a
Tuesday, I believe.'' (R.J. Creasy, private communication, 1989.)

25 R.J. Creasy, General Description of the Research Time-Sharing
System with Special Emphasis on the Control Program, IBM Cambridge
SR&D Center Research Time-Sharing Computer Memorandum 1, Cambridge,
Mass., January 29, 1965. L.W. Comeau, The Philosophy and Logical
Structure of the Control Program, IBM Cambridge SR&D Center Research
Time-Sharing Computer Memorandum 2, Cambridge, Mass., April 15, 1965.

26 For the first few weeks, the CSC people referred to their concept
as a ``pseudo-machine'', but soon adopted the term ``virtual machine''
after hearing Dave Sayre at IBM Research use it to describe a system
he had built for a modified 7044. Sayre's M44 system was similar to
CP-40, except for the crucial difference of not providing a control
program interface that exactly duplicated a real machine. The CP-40
team credited Sayre with having ``implanted the idea that the virtual
machine concept is not necessarily less efficient than more
conventional approaches.'' (L. Talkington, ``A Good Idea and Still
Growing'', White Plains Development Center Newsletter, vol. 2, no. 3,
March, 1969.) ``The system built by Dave Sayre and Bob Nelson was
about as much of a virtual machine system as CTSS---which is to say
that it was close enough to a virtual machine system to show that
`close enough' did not count. I never heard a more eloquent argument
for virtual machines than from Dave Sayre.'' (R.J. Creasy, private
communication, 1990.)

27 ``Dick Bayles was not only a great programmer, he was also the
fastest typist I have ever seen.''  (W.J. Doherty, private
communication, 1990.) ``When Dick Bayles sat down [at a keypunch], he
wrote code as fast as it could punch cards. Yes, the machine was
slower than Bayles composing code on the fly.'' (R.J. Creasy, private
communication, 1989.)

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

checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Thu, 26 Jul 2001 07:51:29 GMT

"Stephen Fuld" writes:

Since there have been lots of answers to number 1 and to you last paragraph,
but none to number 2, I'll take a shot at it.  I am far from an expert here,
but AFAIK you nailed one of the reasons but there are others.

Some people run VM so thy can run lots of CMS users as it is a very
efficient way to support lots of interactive users in, for example, a
university environment.

Some people run VM so they can take advantage of modern hardware to run many
copies of older more limited operating systems such as DOS/VSE which don't
support as much memory, or as many users as more modern hardware does.  This
is exactly the mechanism that people will use to run even hundreds of copies
of Linux on a S/390 (or its new name) system.

Many independent software vendors run it to allow them to support several
versions of several different operating systems in order to assure
compatibility pre ship and for bug reproduction.

one of the things that happened in VM was that since you could operate
the environment "with" and "with/out" the kernel, there was increased
emphasis on kernel efficiency and performance i.e. standard operating
systems tend to claim that the kernel pathlength is what it is, and
maybe we can tweak it a little ... but there was significant more
pressure on the VM kernel to keep in lean and mean.

The other characteristic was that it was much more of a microkernel
with clean division represented by the virtual machine "line". As a
result, it was frequently much easier taks to follow a complete
control flow from end-to-end and optimize it (because of the
simplicity, something that is frequently much more difficult in
kernels that have less clearly defined separation of function).

While it was obvious that a straight forward deployment of another
operating system in a VM virtual machine ... resulted in delta
performance decrease because of the additional VM kernel pathlength,
there was numerous instances where the configuration operations of
another virtual machine could be selected in such away that it traded
off internal management/function for relying on the VM kernel to
provide that management/function. Sometimes the performance
improvement was so significant, that not only did it offset other VM
kernel introduced overhead ... but actually saw significant
performance thruput over running the operating system w/o VM.

The other characteristic was that the CMS interactive environment
(which made significant leverage of such trade-offs) would show
significantly better interactive performance compared to other IBM
"interactive" offerings.

one of these were the famous CERN MVS/TSO VM/CMS benchmark
http://www.garlic.com/~lynn/98.html#28
http://www.garlic.com/~lynn/2000f.html#61
http://www.garlic.com/~lynn/2001f.html#49

I was fortunate enuf to participate in some of the activity
http://www.garlic.com/~lynn/2001e.html#45
http://www.garlic.com/~lynn/2001f.html#62
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#fairshare

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

checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Thu, 26 Jul 2001 08:05:36 GMT

Anne & Lynn Wheeler writes:

one of the things that happened in VM was that since you could operate
the environment "with" and "with/out" the kernel, there was increased
emphasis on kernel efficiency and performance i.e. standard operating
systems tend to claim that the kernel pathlength is what it is, and
maybe we can tweak it a little ... but there was significant more
pressure on the VM kernel to keep in lean and mean.

simple example is between the time that CP/67 was installed at the
university in jan, 1968 where I was an undergraduate and the time I
made presentation at the August '68 SHARE meeting in Boston, I had
reduced many CP/67 pathlengths by a factor of ten to one hundred
times. the following is from that '68 share presentation.

The original CP/67 kernel CPU consumption to execute the referenced OS
MFT14 virtual machine was 856-322 or 534 cpu seconds. By August, I had
rewritten several portions of the kernel and reduced the total CP/67
kernel CPU consumption to 435-322 or 113 cpu seconds for an overall
reduction of a factor of five times (I had also replaced the page
replacement algorithm with a clock-like algorithm, implemented
original fair share scheduling, and done misc. other improvements).

                     OS Performance Studies With CP/67

OS              MFT 14, OS nucleus with 100 entry trace table, 105 record
                in-core job queue, default IBM in-core modules, nucleus total
                size 82k, job scheduler 100k.

HASP            118k Hasp with 1/3 2314 track buffering

Job Stream      25 FORTG compiles

Bare machine    Time to run: 322 sec. (12.9 sec/job)
   times        Time to run just JCL for above: 292 sec. (11.7 sec/job)

Orig. CP/67     Time to run: 856 sec. (34.2 sec/job)
   times        Time to run just JCL for above: 787 sec. (31.5 sec/job)

                Ratio   CP/67 to bare machine

                2.65    Run FORTG compiles
                2.7     to run just JCL
                2.2     Total time less JCL time

1 user, OS on with all of core available less CP/67 program.

Note:   No jobs run with the original CP/67 had ratio times higher than
        the job scheduler. For example, the same 25 jobs were run under WATFOR,
        where they were compiled and executed. Bare machine time was 20 secs.,
        CP/67 time was 44 sec. or a ratio of 2.2. Subtracting 11.7 sec. for
        bare machine time and 31.5 for CP/67 time, a ratio for WATFOR less
        job scheduler time was 1.5.

        I hand built the OS MFT system with careful ordering of
        cards in the stage-two sysgen to optimize placement of data sets,
        and members in SYS1.LINKLIB and SYS1.SVCLIB.

                            MODIFIED CP/67

OS run with one other user. The other user was not active, was just
available to control amount of core used by OS. The following table
gives core available to OS, execution time and execution time ratio
for the 25 FORTG compiles.

CORE (pages)    OS with Hasp            OS w/o HASP

104             1.35 (435 sec)
 94             1.37 (445 sec)
 74             1.38 (450 sec)          1.49 (480 sec)
 64             1.89 (610 sec)          1.49 (480 sec)
 54             2.32 (750 sec)          1.81 (585 sec)
 44             4.53 (1450 sec)         1.96 (630 sec)

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

VM: checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Thu, 26 Jul 2001 08:39:26 GMT

hack@watson.ibm.com (hack) writes:

Historically, the coupling between virtual card punches and readers (across
the RSCS company-wide network, aka VNET) was the primary communication
interface (nearly 30 years old).  It may sound quaint, but it's really just
a data pipe (with 80-byte blocks) with tagged ends to perform the connection,
and it has a really simple interface (no connection protocols etc. -- the
network is store-and-forward, so it's literally like mailing postcards where
bunches (individual "spool files") are guaranteed to arrive in order (there
is no virtual equivalent to a deck of cards spilled on the floor).

one of the problems with the "spool file" interface was that it was
synchronous on open, close and on 4k buffer boundaries doing various
disk I/O (whether it was using straight UR simulation or 4k block
transfers). in the mid-80s, a VNET virtual machine supporting even a
few full-duplex 56kbit links could spend 90% of elapsed time in
"blocked" state waiting on synchronous (disk) spool file operations.

one of the things that we did in HSDT was implement several
asynchronous functions for VNET so we could start seeing it drive
multiple full-duplex T1 links at media thruput.

In HSDT, we also got the mainframe TCP/IP thruput up from 44kbybtes/sec
to hardware channel speed.

random refs:
http://www.garlic.com/~lynn/subtopic.html#hsdt
http://www.garlic.com/~lynn/subtopic.html#xtphsp
http://www.garlic.com/~lynn/internet.htm

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

Installing Fortran

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Installing Fortran
Newsgroups: alt.folklore.computers
Date: Sun, 29 Jul 2001 12:35:47 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:

Yupper.  Once your program started executing, all addresses were
fixed in genuine core storage.  If that program was obstructing the
execution of the higher priority task of bean counting, the exact
core image could be written to disk at a suitable breakpoint, then
restarted.  Service bureaus didn't like this feature - played havoc
with tapes, printers, card readers and disk files (including the
system catalog).  Along came VM or MVS to simplify life in the job
scheduling lane.  Aren't we all glad that M$ came along?

Boeing Huntsville .... took a version of OS/360 MVT Release 13 and added
virtual memory support running on two-processor SMP 360/67. Their
application was multiple large interactive graphic programs using 2250s.
This system didn't support paging. The problem was that MVT programming
model required contiguous storage allocation for programs all sharing the
same (real) address space. An environment with multiple long running
programs had severe storage fragmentation problems. The virtual memory
support allowed for overcoming the storage fragmentation problems. This
would have been early to mid 68. The application was discontinued the
summer of  '69 and the 67s shipped to Boeing Seattle..

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

IBM 9020 FAA/ATC Systems from 1960's

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 9020 FAA/ATC Systems from 1960's
Newsgroups: alt.folklore.computers
Date: Mon, 30 Jul 2001 12:24:07 GMT

Nick Spalding writes:

My Green Card GX20-1703-9 has TS on it.  Anyone know what date the -9
represents?

nope, but it is also in my -7. it seems to have been in all the
original 360s.

I did alta-vista search on 9020 and came up with a couple hits.

http://www.faa.gov/apa/speeches/aoa/FWINGS.htm

Automation of en route ATC began with the installation of IBM's
prototype 9020 system at the Jacksonville Center in 1967. Designed to
provide automated flight data processing and radar tracking at all en
route centers and major terminals, this was the most complex computer
application ever undertaken up to that time. Its half million commands
required more than twice the amount of memory originally planned, a
complication which caused the project to fall behind schedule. The
installation at all 22 en route centers was not completed until the
end of the 1970s.

http://www.aero-space.nasa.gov/library/ch1.htm

Automation of en route ATC began with the installation of IBM's
prototype 9020 system at the Jacksonville Center in 1967. The system
was designed to provide automated flight data processing and radar
tracking at all en route centers and major terminals. The system was
delivered behind schedule, which created significant frustration
within FAA, the aviation community and IBM. The system would not be in
place at all 22 en route centers until the end of the 1970s. However,
indicative of the complex nature of automating the en route
environment, the 9020 system proved to be the most complex computer
application in the world at the time, with more than half a million
commands. When the program was completed, IBM had more than doubled
the amount of memory the company had first thought the program would
require.

http://api.hq.faa.gov/96sp-fin.htm

http://catless.ncl.ac.uk/Risks/5.67.html

http://home.columbus.rr.com/lusch/index.html

HOCSR (Host and Oceanic Computer Replacement System)
http://www.faa.gov/aua/ipt_prod/enroute/hocsrfct.htm

A system-wide upgrade completed in 1999 at the 20 Air Route Traffic
Control Centers. It is the heart of the system in that it receives,
processes, coordinates, distributes and tracks information on aircraft
movements throughout domestic and oceanic airspace. It replaced the
HOST computers that ten years earlier had replaced the old IBM 9020
computers. [Back]

HOST

A system-wide computer upgrade completed in 1989 at the 20 Air Route
Traffic Control Centers. HOST replaced the old IBM 9020 computers. It has
since been superseded by HOCSR. [Back]

http://www.faa.gov/aua/ipt_prod/enroute/hocsrfct.htm

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

D

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: D
Newsgroups: alt.folklore.computers
Date: Mon, 30 Jul 2001 13:23:30 GMT

cb@df.lth.se (Christian Brunschen) writes:

I seem to recall hearing a rumor (and as such it is of course totally
unsubstantiated) that a US government intelligence agency is reviewing an
open-source OS' source code for security, to see if they can use it
instead of thproven buggy, closed system (Windows) that they currently
use. Again, rumor, hearsay, and I may even be misremembering the few facts
I present here.

http://www.nsa.gov/selinux/index.html

as an aside, i finally got around to updating my security glossary with
glosary from Infromation Assurance Technical Framework release 3.

http://www.garlic.com/~lynn/secure.htm

notes on source of terms
http://www.garlic.com/~lynn/index.html#glosnote

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

IBM 9020 FAA/ATC Systems from 1960's

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 9020 FAA/ATC Systems from 1960's
Newsgroups: alt.folklore.computers
Date: Mon, 30 Jul 2001 17:22:19 GMT

jcmorris@mitre.org (Joe Morris) writes:

If TS was added to support the ATC requirements, why was it the only
one of those specialized opcodes to make it into the standard PoO?
(Perhaps because it alone did not rely on any particular data
structure that was unique to the FAA software?)

TS was used for multiprocessing support in both 360m65 (os/360) and
360m67 (tss/360 & cp/67). Both predated the ATC work (although ATC may
have taken advantage of some of the 360m65 multiprocessor work).

my understanding was that the 65 & 67 were originally going to be
360m60 and 360m62 ... but somewhere along the line, there was an
upgrade to the memory technology (to 750ns) and the numbers got
changed.

as an aside, the work at cambridge on fine grain locking with cp/67
directly led to compare&swap instruction in 370 (in fact, "CAS" are
the person's initials that did most of the work at cambridge, and
the trick was to come up with a mnemonic that was his initials;
it got modified to CS & CDS tho).

random refs:
http://www.garlic.com/~lynn/subtopic.html#smp

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

checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Mon, 30 Jul 2001 18:02:02 GMT

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

In actual fact, there are bugs that can creep by the 3-level test
for both compilers and VMs, but they are mind-bogglingly obscure
by comparison with the ones that adding the third level picks up.

for the resource manager ... I developed an automated benchmarking
system that would generate kernels, auto-reboot, run benchmarks, build
new kernels, run more benchmarks ... and it would run & run & run. The
basic set was 2000 benchmarks that took three months elapsed time to
run (before initial product release).

The benchmarking attempting to choose workloads along the edge of the
"normal" observed operational envelopes, random points withing the
envelope and some number of operations that were way outside any
normal envelope ... say saturating a couple fixed-head paging devices
(hundreds of pages/sec), with huge queues and average service time of
1second.

These outside the envelope benchmarks tended to precipitate zombie
user conditions and numerous timing failures. In order to eliminate
all such cases (from the normal system), I had to totally rewrite the
system serialization primitives in order to eliminate all possible
occurances of zombies & kernel failures because of various asynchronous
timing problems.

random refs:
http://www.garlic.com/~lynn/94.html#52
http://www.garlic.com/~lynn/2001c.html#13
http://www.garlic.com/~lynn/2001e.html#45
http://www.garlic.com/~lynn/2001f.html#56
http://www.garlic.com/~lynn/subtopic.html#fairshare

and of course, my favorite "envelope" subject:
http://www.garlic.com/~lynn/subtopic.html#boyd

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

checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Mon, 30 Jul 2001 17:47:11 GMT

Greg Pfister writes:

Related -- Once upon a time that same friend told me that you
actually have to be able to do three levels of virtualization of
memory to be general -- the top-level VM system just doing it is
not enough; you have to be able to nest a VM system virtualizing
what the top-level system is also virtualizing, and a third level
below that. I never did understand why the third level was
necessary, but this guy was very, very good and knew that code
intimately, so he was probably right.

multi-level reference
http://www.garlic.com/~lynn/99.html#7

three levels of CP/67 under which ran CMS. standard cp/67 running on
the real hardware in an "open" environment (university students &
others on effectively a public access machine),

then a modified CP/67 running in "360m67" mode ... but providing 370
virtual machines (primarily relocation tables different structure
between 360m67 & 370), and then a further modified CP/67 running in
"370" mode ... which then provided 370 virtual machines (running CMS)
... aka

     real 360m67
-      cp/67
        standard 360 & 360/67 virtual machines
-         CP/67 modified to provide 370 virtual machine
            370 "R" virtual machines
-             CP/67 modified to run on 370 w/virtual memory
                370 "R" virtual machines
-                 CMS

This was about two years before virtual memory was available on 370
(and possibly a year before 370 engineering models with virtual memory
were available). Issue was to try and obscure the fact that
development for unannounced (or even unavailable) products was going
on.

while there was quite a bit of use of CP/67 & VM/370 inside the
corporation for the testing of new operating systems ... in terms of
CPU cycles, probably the biggest use was straight interactive
computing (edits, compiles, non-operating system testing, email,
documents, GML, etc). Part of this give rise to the largest network
in the world (larger than arpanet until around '85)

'83 ... had nearly 1000 mainframe nodes at point when arpanet was about
255 total nodes. random refs:
http://www.garlic.com/~lynn/99.html#112

there was another way of getting machine time. the disk engineering
labs were doing all their development in a stand-alone environment
(MVS with a single "test-cell" MTBF was on the order of 15 minutes).
I rewrote i/o supervisor so it wouldn't fail & they could operate 6-12
test-cells concurrently. The priority list on processors ... was that
typicall as soon as the CPU/processors engineers had the 2nd one
running; it was made available to the disk engineering labs for their
testing.

random refs:
http://www.garlic.com/~lynn/2000d.html#0
http://www.garlic.com/~lynn/subtopic.html#disk

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

physical vs. virtual addresses

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: physical vs. virtual addresses
Newsgroups: comp.arch
Date: Mon, 30 Jul 2001 18:22:37 GMT

hack@watson.ibm.com (hack) writes:

It's a win when there are 10,000 logged-on interactive CMS users on a
large VM system -- it improves interactive response time tremendously
for the much smaller subset of concurrently active users.

random refs:
http://www.garlic.com/~lynn/93.html#5 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2000g.html#38 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#42 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#43 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#44 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#45 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#47 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2000g.html#51 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2000g.html#52 > 512 byte disk blocks (was: 4M pages are a bad idea)
http://www.garlic.com/~lynn/2001.html#1 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
http://www.garlic.com/~lynn/2001c.html#16 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#48 database (or b-tree) page sizes

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

checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Mon, 30 Jul 2001 18:37:59 GMT

Anne & Lynn Wheeler writes:

'83 ... had nearly 1000 mainframe nodes at point when arpanet was about
255 total nodes. random refs:
http://www.garlic.com/~lynn/99.html#112

oops that should be
http://www.garlic.com/~lynn/99.html#112

also some discussion at
http://www.garlic.com/~lynn/internet.htm

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

Intel's new GBE card?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel's new GBE card?
Newsgroups: comp.arch.storage
Date: Mon, 30 Jul 2001 19:21:19 GMT

Rick Jones writes:

Support for hardware checksum offload in networking stacks goes back
at least to the late '80's/early 90's. OSes such as IRIX and HP-UX
were among them. I suspect a couple others were there at the time
too. Perhaps Digital Unix/OSF1. Later that did trickle-down to the
commodeity space.

Indeed, unless one has a really ugly stack implementation, the things
you need/want to offload are those things that require "accessing" the
data. That would certainly include the checksum computation, and if
that offload also allows for copy avoidance even better.

At least SGI was very active in the late '80s .... some engineers that
had worked on the high-speed pipelining of the (graphics) geometry
engine were working on a high-speed pipelined "protocol engine" for
network protocol (which including things like moving the checksum in
the header to the trailer).

the trick at the time was to come as close as possible to saturating
100mbit FDDI medium w/o disolving the CPU (the time since then, the CPUs
have gotten significantly faster)

random refs:
http://www.garlic.com/~lynn/99.html#0 Early tcp development?
http://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#207 Life-Advancing Work of Timothy Berners-Lee
http://www.garlic.com/~lynn/2000b.html#5 "Mainframe" Usage
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001b.html#11 Review of the Intel C/C++ compiler for Windows
http://www.garlic.com/~lynn/2001b.html#57 I am fed up!
http://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001e.html#34 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001h.html#13 VM: checking some myths.

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

Redhat 7.2?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Redhat 7.2?
Newsgroups: comp.os.linux.questions,comp.os.linux.help,linux.redhat,comp.os.linux.setup
Date: Mon, 30 Jul 2001 22:15:23 GMT

I was in frankfurt two weeks ago ... and saw (german) Redhat 7.2 for
sale in window of store (about half-block down side street off main
shopping mall).

Is this something that specific to germany?

I've not seen it in any stores in the US yet?

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

"Hollerith" card code to EBCDIC conversion

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Hollerith" card code to EBCDIC conversion
Newsgroups: alt.folklore.computers
Date: Mon, 30 Jul 2001 23:48:35 GMT

Eric Fischer writes:

There are lots of special cases in the conversion between the "Hollerith"
card code and its representation as 8-bit EBCDIC.  How do IBM 360-series
systems deal with this?  Is there a lookup table?  Hardware assistance?

The conversion to 6-bit BCDIC doesn't have as many special cases, but
does have a few.  IBM 70x systems had to read cards bit-by-bit, right?
Was there a standard algorithm that everyone used to do the conversion?

i worked with 2540 card reader that was originally (I believe attached)
to 1401 ... and then attached to a 360m30 (running both 1401 emulation
and os/360).

I had a job to rewrite the 1401 unit record (ur<->tape) front-end for
709 to run on 360m30. While I was writing the program, they would
switch the machine back & forth between 1401-mode and running other
360 programs (and testing my program).

Cards could be either binary or bcd. If they were binary, you would
read with column-binary command which would place 80 columns of data
into 160 bytes (effectively two 6-bit values per column mapped into
two 8-bit bytes). If it was BCD ... then it was just BCD read into one
byte.

"greencard" gives the mapping of bit patterns to punch holes for BCDIC
& EBCDIC (as well as mapping to 7track tape). The issue wasn't so much
what the bit pattern was ... but what character the bit pattern
represented depending on whether you were treating it as BCDIC or
EBCDIC ... aka punch 0-6-8 comes in as hex "6E" ... but is backslash
in BCDIC and greater-than in EBCDIC.

random refs:
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/93.html#17 unit record & other controllers
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
http://www.garlic.com/~lynn/96.html#20 1401 series emulation still running?
http://www.garlic.com/~lynn/97.html#7 Did 1401 have time?
http://www.garlic.com/~lynn/97.html#21 IBM 1401's claim to fame
http://www.garlic.com/~lynn/98.html#9  Old Vintage Operating Systems
http://www.garlic.com/~lynn/98.html#14 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#53 punch card editing, take 2
http://www.garlic.com/~lynn/98.html#55 Multics
http://www.garlic.com/~lynn/99.html#13 Old Computers
http://www.garlic.com/~lynn/99.html#59 Living legends
http://www.garlic.com/~lynn/99.html#86 1401 Wordmark?
http://www.garlic.com/~lynn/99.html#87 1401 Wordmark?
http://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/99.html#130 early hardware
http://www.garlic.com/~lynn/99.html#137 Mainframe emulation
http://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#194 1403 printer on a 1401?
http://www.garlic.com/~lynn/2000.html#55 OS/360 JCL: The DD statement and DCBs
http://www.garlic.com/~lynn/2000.html#79 Mainframe operating systems
http://www.garlic.com/~lynn/2000b.html#6 ascii to binary
http://www.garlic.com/~lynn/2000c.html#11 IBM 1460
http://www.garlic.com/~lynn/2000d.html#34 Assembly language formatting on IBM systems
http://www.garlic.com/~lynn/2001.html#11 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001.html#16 Sv: IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001b.html#20 HELP
http://www.garlic.com/~lynn/2001b.html#22 HELP
http://www.garlic.com/~lynn/2001b.html#27 HELP
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001c.html#22 OS for IBM 370
http://www.garlic.com/~lynn/2001c.html#87 "Bootstrap"
http://www.garlic.com/~lynn/2001e.html#13 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001f.html#5 Emulation (was Re: Object code (was: Source code - couldn't resist compiling it :-))
http://www.garlic.com/~lynn/2001f.html#36 Ancient computer humor - The Condemned
http://www.garlic.com/~lynn/2001f.html#37 Ancient computer humor - Memory
http://www.garlic.com/~lynn/2001f.html#38 Ancient computer humor - Gen A Sys
http://www.garlic.com/~lynn/2001f.html#39 Ancient computer humor - DEC WARS
http://www.garlic.com/~lynn/2001g.html#22 Golden Era of Compilers
http://www.garlic.com/~lynn/2001g.html#27 Golden Era of Compilers
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.

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

earthlink timing out nntp connections

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: earthlink timing out nntp connections
Newsgroups: gnu.emacs.gnus
Date: Tue, 31 Jul 2001 11:32:11 GMT

within the last week or so, earthlink appears to have started timing
out nntp connections after only something like 30-60 seconds. if you
spend too long reading an article ... the connection has timed out
before you move on to the next article ... or if you are typing a
reply. it plays quite a bit of havok with gnus 5.8.8.

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

TECO Critique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TECO Critique
Newsgroups: alt.folklore.computers
Date: Tue, 31 Jul 2001 12:21:37 GMT

jmfbahciv writes:

What are you talking about?  The two are mutually exclusive.
One is a way to address memory, the other is a way to manage
memory.

it is possible that it is demand paging vis-a-vis  swapping.

demand paging typically waits for a page-fault at a time and does
a/one page block transfer. there are various kinds of page replacement
algorithms associated with this. paging also has to do with virtual
memory support ... which page faults & demand paging can be a part of,
although there has been some number of systems that are simply used
for memory mapping (like overcoming memory fragmentation problems).

swapping tends to be a task management oriented event. CTSS would
swap/roll-out whole task and then swap/roll-in a different task.

various optimizations are possible with swapping ... and can even work
with a demand paging system. at some task deactivation event all pages
for a task are written out at one time (and the pages with reference
bit on are remembered), later when the task is re-activated all the
referenced pages are read back in at one time. between task activation
and deactivation ... the system could manage the task with demand
paging.

boeing huntsville modified MVT for just virtual address mapping to
address a (contiguous address) memory fragmentation problem they had
(w/o any page faults, or demand paging or swapping).

http://www.garlic.com/~lynn/2001.html#14

there are intermediate situations between demand paging and task
swapping ... like what was done in vm/hpo in the early 80s where
"swap" was managed in groups of blocks of ten pages (rather than all
pages). on deactivation/outgoing ... pages were clustered in groups of
ten pages for writing. on activation, a hybrid demand paging/swap
occured where a page fault for a page this is part of a group would
bring in all ten pages in that group.

http://www.garlic.com/~lynn/2001h.html#20

& something from a recent mailing list

>         What is footnote 23, or more directly, where can I read more
>about Atlas's VM problems. Lord knows I have plenty of experience
>(as a user) with badly implemented VM, but what was the "killer"?

I don't know specifically what Atlas's problem was. I know that the CP/67
support of demand paging wasn't very good when I first saw it in Jan. 1968,
however, TSS/360's was even worse (the university that I was at had been
doing TSS tests on & off during '67 & '68, primary reason that it was
investigating CP/67 was because TSS performance was so abysmal).

There were actually a couple problems

1) page replacement algorithm
2) path length
3) disk/drum (fixed-head disk) I/O optimization
4) disk/drum migration
5) thrashing controls.

CP/67 didn't have #4 ... and the rest was very poor.

TSS/360 had something #4 ... but it actually caused more problems than it
solved. A task that woke up or made it out of the thrashing control list
... got all its pages moved from 2311 (moveable arm disk) to 2301 (moveable
arm disk) before actually executing. When it went idle (say between simple
edit commands), all its pages were swept from the 2301 back to 2311. This
happened even if there was no contention for space on the 2301. It wasn't
optimized for relying on pages that might be laying around in real memory.

With regard to CP/67, I rewrote most of the code while also doing the
pathlength optimization for running OS/360.

I created the first "clock" replacement algorithm, my own method of
estimating "working set" for page thrashing controls, very short pathlength
implementation, ordered seek queuing for normal disks (help both page i/o
as well as disk i/o), and some 2301 optimization (as well as early form of
my dynamic adaptive feedback scheduler including "fairshare"). The "clock"
replacement algorithm, I later refined after graduation when I joined
cambridge scientific center in 1970.

There was a "working set" paper published in ACM sometime '68
... about a particular kind of page replacement and thrashing controls
where were significantly worse than what I had implemented.

Nearly 15 years later (after I had first implemented clock) a stanford
Phd thesis was done on "clock" replacement and the "working set"
author strenuously objected. In a very round-about trail ... I was
finally asked to provide supporting evidence (so the guy could get his
Phd). There had been a paper in the early '70s by the Grenoble
Scientific Center that had modified CP/67 with an "exact"
implementation of Denning's definition and benchmarks published in an
ACM article running with 30 users on a 1mbyte 360/67 (about 155 pages
after fixed kernel requirements). The performance (for the same
workload mix) was about the same I was getting at the same time on a
768k 360/67 (104 pages after fixed kernel requirements) with 75 users.

random refs:
http://www.garlic.com/~lynn/94.html#49
http://www.garlic.com/~lynn/2001g.html#29
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#fairshare

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

TECO Critique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TECO Critique
Newsgroups: alt.folklore.computers
Date: Tue, 31 Jul 2001 13:08:38 GMT

Anne & Lynn Wheeler writes:

http://www.garlic.com/~lynn/2001.html#14

oops, that should be
http://www.garlic.com/~lynn/2001h.html#14
                                ^
--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Tue, 31 Jul 2001 13:48:55 GMT

jcmorris@mitre.org (Joe Morris) writes:

Of course, nothing brings out the bugs like putting a system into
production...no matter how thoroughly you test for broken responses
to pathological conditions, some user will find a new way to expose
a failure mode.

Joe Morris

misc. refs: from disk controller testing
http://www.garlic.com/~lynn/96.html#18
http://www.garlic.com/~lynn/96.html#19
http://www.garlic.com/~lynn/subtopic.html#disk

basically the "acceptance" test for 3880 was that it was within +/-10%
of the 3830 performance. the problem was that while the 3880
supporting data streaming 3mbyte transfers ... it did it with custom
hardware for the data path and a jib' microcontroller for the control
path (the 3830 had been all a fast horizontal microcoded engine). The
jib' was taking quite a bit longer to do clean-up after an operation
finished ... so to meet the performance criteria ... they started
presenting operation finished interrupt "early" (before the jib' had
finished all its clean-up). This worked OK for the acceptance test
which was with a one-pack/drive, single task VS1 system.

The problem was the weekend the product test lab replaced a production
16-drive 3830 configuration with one of the 3880 controllers. I got
the call bright and early monday morning to come fix a operating
system problem (performance had all gone to $%#!). Finally was able to
trace it back to the "new" 3880. Fortunately this was six months
before first customer ship ... and allowed the engineers some time to
make other adjustments to address the issues.

The problem was that with multiple drives (and high level of
multitasking) on the same controller, there were frequently requests
queued because of channel, controller, and/or device busy. When the
controller signaled operation complete interrupt ... the operating
system would immediately hit/redrive it with a queued request.
Because the jib' had signaled "complete" early, it was actually still
busy ... and so the redrive operation got a "control unit busy"
response. The system then went off to do something else. Eventually,
the jib' finished and because it had signaled a control unit busy
condition, it then had to signal a control unit end interrupt. With
this, the system then attempts to restart the redrive operation (which
would typically succeed this time).

The extra operation and interrupts .... in addition to the increase in
operation latency made things look like a 80-90% system degradation.

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

checking some myths.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: checking some myths.
Newsgroups: comp.os.vms,comp.unix.tru64,comp.arch,alt.folklore.computers
Date: Tue, 31 Jul 2001 14:09:32 GMT

jcmorris@mitre.org (Joe Morris) writes:

Of course, nothing brings out the bugs like putting a system into
production...no matter how thoroughly you test for broken responses
to pathological conditions, some user will find a new way to expose
a failure mode.

... i was fortunate at the time to have a lot of responsible for some
the research production systems, the disk enginnearing production
systems, the disk product test lab production systems, systems at one
of the VLSI labs, and a lot of the HONE production systems ... and was
able to relatively easily drop new code onto their production floors
for some "rubber meets the road" (the downside was I had to
fix/support a lot of their other problems/issues).

I joke at one point I was working first shift in research (bldg. 28),
2nd shift in GPD (disk engineering &test, bldg. 14&15), and 3rd shift in STL
(on a project supporting IMS group, bldg. 90) with periodic visits to
palo alto for hone (one street over from page mill).

random refs:
http://www.garlic.com/~lynn/subtopic.html#disk
http://www.garlic.com/~lynn/subtopic.html#hone
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#hsdt

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

earthlink timing out nntp connections

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: earthlink timing out nntp connections
Newsgroups: gnu.emacs.gnus
Date: Tue, 31 Jul 2001 14:19:33 GMT

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

Gnus should open the connection again when needed.  Does this not
happen for you?  Please provide more details how Gnus fails to do that.

kai

If i'm entering a newsgroup, it will re-open. If i'm posting ... it
hangs for either a couple minutes and eventually says connection
closed (I then go back up to the group buffer and do a get, which
re-opens the connection) or it hangs for at least 10 minutes (i've
never waited longer than that).

If it looks like it is hanging forever, I can hang up the modem and
that wakes gnus up and it says connection closed. I then reconnect the
modem and do as above.

Once the modem is reconnected I can then go to the group buffer and do
a get, which re-opens the connection, and then go to the posting
buffer and attempt to repost it (however, if i delay a little ... say
I'm off doing something in another window while waiting for all the
stuff to get back together again ... I can find myself back in the
original situation all over again).

doing a get in the group buffer seems the most reliable way of getting
gnus to re-open the connection (other than quiting completely out
and restarting).

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

earthlink timing out nntp connections

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: earthlink timing out nntp connections
Newsgroups: gnu.emacs.gnus
Date: Tue, 31 Jul 2001 14:46:20 GMT

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

Gnus should open the connection again when needed.  Does this not
happen for you?  Please provide more details how Gnus fails to do that.

also, sporadically just entering a newsgroup will hang (w/o automatically
reopening the connection) and I have to resort to cycling the modem
connection which brings it out of it ... and then I retry reentering
the newsgroup and it succesfully re-opens the connection.

and possibly one out of 50? (maybe once a day) it just hangs and
nothing I do brings it back ... and I eventually have to kill
gnuemacs.

this started happening with gnuemacs 20.6.1 on nt4 with gnus 5.8.8
about 10 days ago ... couple days ago i upgraded to gnuemacs 20.7.1
and it hasn't made any difference.

previous posting wasn't a problem ... but i had to cycle the modem
connection for this posting

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

Wanted: pictures of green-screen text

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wanted: pictures of green-screen text
Newsgroups: alt.folklore.computers
Date: Tue, 31 Jul 2001 15:01:20 GMT

Tim Shoppa writes:

Wouldn't it be more "faithful" to use a font more along the line
of a Teletype ASR33?  (Or Model 28, or...)  You had to be rich to afford a
green screen in 1976...

when did the TI silent 700s show up? I remember having one for a home
terminal in the late '70s before getting a ibm 3101 (at the office it
was mostly 327xs).

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

D

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: D
Newsgroups: alt.folklore.computers
Date: Wed, 01 Aug 2001 23:28:00 GMT

ftit@red.engin.umich.edu (Sergej Roytman) writes:

Hm, that is a pretty scary thought.  All the IBMs I've worked with,
dinos and otherwise, looked as if they had been programmed by Martians.
Smart Martians, of course, who wrote solid code, but who did not think
in quite the same way as people from my planet.

Any thoughts about IBM looking into Linux, by the way?  I thought they
suffered too badly from NIH to ever do something like this.

there was a reference to bringing up 41k-some different Linux copies in
a small LPAR on a 390.

LPAR is a subset of the virtual machine function that allows a 390 to
be partitioned into multiple logical machines (or logical partitions
i.e.  Logical PARtitions). You can dedicate resources to a logical
partition as well as specify resources (like amount of cpu cycles).
Within an LPAR you can run any mainframe operating system ... included
the VM (or virtual machine) operating system. A test was done in such
a configuration with a 41,000+ virtual machines each running a copy
of Linux under a VM (virtual machine) operating system running in
a "small" LPAR (i.e. configured with minimal resources)

a couple refs to linux 390
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again . . .
http://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2001h.html#11 checking some myths.

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

D

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: D
Newsgroups: alt.folklore.computers
Date: Thu, 02 Aug 2001 16:54:15 GMT

jmfbahciv writes:

Hm, that is a pretty scary thought.  All the IBMs I've worked with,
dinos and otherwise, looked as if they had been programmed by Martians.
Smart Martians, of course, who wrote solid code, but who did not think
in quite the same way as people from my planet.

They never did timesharing.  Their whole company folklore is based
on cards.  This doesn't make them wrong...just different and very
useful with certain kinds of computing.

you may be talking about the majority of the company ... but the
Cambridge science center turned out CP/67, CMS, VM/370, internal
network, lots of email and networking apps, GML (precursor to SGML,
HTML, XML), etc. Several of the people had come from CTSS.

In a posting some time ago, I made the observation that the perception
of the company was totally card based .... not because it didn't have
time-sharing effort larger than possibly any other company out there
... but because its time-sharing effort was totally dwarfed by the
batch/business/card business (aka if the company's time-sharing
business had been some other company ... it would have been considered
the largest time-sharing business around ... but because it was part
of a company that had an even larger batch/business business ... the
time-sharing effort has been somewhat discounted).

I joke at one time, that I personally made system distribution tapes
for a number of internal installations ... at one time the number of
those sites was larger than the total number of multics installations
(the total number of internal sites was significantly larger than the
number of sites that I directly distributed system tapes to, a number
that on the internal network ... made the internal network the largest
network in the world for the '70s and much of the '80s ... and the
total number of internal sites was yet smaller still than the number
of external customer sites).

random refs:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#hone
http://www.garlic.com/~lynn/subtopic.html#smp

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

D

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: D
Newsgroups: alt.folklore.computers
Date: Fri, 03 Aug 2001 13:28:07 GMT

jmfbahciv writes:

No.  I'm talking about a basic computing philosophy.  I forgot
to point out that IBM's idea of timesharing is not our
idea of timesharing.  I've never been able to describe this
difference well.

as noted before ... while timesharing was somewhat anti-thetical to
much of the batch/card infrastructure products ... ibm did produce
time-sharing for customers ... which was also taken and was the
platform offering by a number of time-sharing service bureaus ... like
tymshare.

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

PKI/Digital signature doesn't work

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PKI/Digital signature doesn't work
Newsgroups: sci.crypt
Date: 03 Aug 2001 18:04:35 -0600

Anne & Lynn Wheeler writes:

There already have been debit network pilots ... and work is underway
for production roll-outs.

misc. refs:
http://www.garlic.com/~lynn/nacharfi.htm
http://www.garlic.com/~lynn/99.html#224
http://www.garlic.com/~lynn/aadsmore.htm#nacha

the results of the above are now available. NACHA is the (US) National
Automated Clearing House Association  ... the nacha web site.

http://www.nacha.org/

presss release ("digital signatures can secure ATM card payments on
the Internet")

http://www.nacha.org/news/news/pressreleases/2001/PR072301/pr072301.htm

results

http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

the report

http://internetcouncil.nacha.org/Projects/ISAP_Results/ISAPresultsDocument-Final-2.PDF

includes the following from the above ...

The "real-world" viability of the proposed ANSI X9.59 standard concept
for electronic payments using public/private key pairs, which is also
known as Account Authority Digital Signature (AADS), was validated by
the ISAP Pilot results. These results demonstrate the feasibility of
using PKI without digital certificates, thereby minimizing
infrastructure requirements and costs for utilizing the ISAP process.

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

Credit Card # encryption

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Sun, 05 Aug 2001 19:59:49 GMT

"Tor Rustad" writes:

If the attacker can get the public key and a copy the database, your system
is trivial to break.

I don't think Visa or Mastercard are very happy about merchants storing
credit card numbers at all. In fact they don't trust the Administrator
either...just look at the SET protocol.

You are perhaps re-inventing the weel here, ask the credit card companies
for help, else you risk a NJET later on.

the merchants need to keep the original transaction and the credit card
numbers as part of standard credit card business process ... even with
SET.

For more discussion with regard to the SET aspects see:

http://www.garlic.com/~lynn/aepay7.htm#nonrep2
http://www.garlic.com/~lynn/aepay7.htm#nonrep3
http://www.garlic.com/~lynn/aepay7.htm#nonrep4
http://www.garlic.com/~lynn/aepay7.htm#nonrep5
http://www.garlic.com/~lynn/aepay7.htm#nonrep6

X9.59 over comes the problem of account-number harvesting for
fraudulent purposes for all account-based payments (not just internet,
not just point-of-sale, not just credit, not just debit, etc)

recent posting with regard to X9.59 (specific to debit/atm card
implementation)

press release ("digital signatures can secure ATM card payments on the
Internet")

http://www.nacha.org/news/news/pressreleases/2001/PR072301/pr072301.htm

results

http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

the report

http://internetcouncil.nacha.org/Projects/ISAP_Results/ISAPresultsDocument-Final-2.PDF

includes the following from the above ...

The "real-world" viability of the proposed ANSI X9.59 standard concept
for electronic payments using public/private key pairs, which is also
known as Account Authority Digital Signature (AADS), was validated by
the ISAP Pilot results. These results demonstrate the feasibility of
using PKI without digital certificates, thereby minimizing
infrastructure requirements and costs for utilizing the ISAP process.

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

The rfi for the above:

http://www.garlic.com/~lynn/nacharfi.htm

additional information on x9.59 and AADS

http://www.garlic.com/~lynn

nacha web site

http://www.nacha.org/

nacha organization

Welcome to NACHA

Welcome to the web site of NACHA - The Electronic Payments
Association.  Here you will find the latest information on the
innovative and dynamic world of electronic payments.

Electronic payments of all kinds are used frequently by people,
companies, and government agencies as a safe, reliable and convenient
way to conduct business. Direct Deposit is used for payroll, travel
and expense reimbursements, annuities and pensions, dividends, and
government payments such as Social Security and Veterans
benefits. Other types of electronic payments are frequently used for
bill payments, retail purchases, Internet purchases, corporate
payments and treasury management, and for the provision of food stamps
and other government cash assistance.

NACHA is a not-for-profit trade association that develops operating
rules and business practices for the Automated Clearing House (ACH)
Network and for other areas of electronic payments.  NACHA activities
and initiatives facilitate the adoption of electronic payments in the
areas of Internet commerce, electronic bill payment and presentment
(EBPP), financial electronic data interchange (EDI), international
payments, electronic checks, electronic benefits transfer (EBT) and
student lending. We also promote the use of electronic payment
products and services, such as Direct Deposit and Direct Payment.

NACHA represents more than 12,000 financial institutions through our
network of regional ACH associations.  We have over 600 members in our
seven industry councils and corporate Affiliate Membership program.

I hope you will find this web site to be a valuable resource.  Please
come again!

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

Credit Card # encryption

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Mon, 06 Aug 2001 13:08:05 GMT

"Tor Rustad" writes:

In the Preq message, the Payment Inforstruction (PI) is encrypted with a
Payment Gateway key at the cardholder side, hence the merchant can't decrypt
PI and get the PAN. Transactions can of course be matched by other
identifiers, so the merchant doesn't need the PAN.

What am I missing here?

the following from:

http://www.garlic.com/~lynn/aepay7.htm#nonrep5
http://lists.commerce.net/archives/ansi-epay/199905/msg00009.html

It was never even a minor purpose of the SET specification work to
eliminate credit card numbers from being known by the merchant.

The fact that the merchant does not see the account number on the way
to the payment gateway was touted by some as a benefit of the system,
but it was a side effect of the design. There was never a stated (or
even implied) requirement to hide the account number from the
merchant.

posted Fri, 7 May 1999, 14.59.11 -0700 to ansi-epay@lists.commerce.net by tlewis@xxxxxxxx

now, when I originally (long ago and far away) raised the issue that
somebody could take advantage of the CC# getting to the payment
gateway and not return it to the merchant ... but as stated, in the
above quote as well as earlier .. "it was never even a minor purpose
of SET specification work to eliminate the credit card numbers from
being known by the merchant".

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

Credit Card # encryption

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Mon, 06 Aug 2001 13:14:44 GMT

Anne & Lynn Wheeler writes:

....

It was never even a minor purpose of the SET specification work to
eliminate credit card numbers from being known by the merchant.

The fact that the merchant does not see the account number on the way
to the payment gateway was touted by some as a benefit of the system,
but it was a side effect of the design. There was never a stated (or
even implied) requirement to hide the account number from the
merchant.

....

posted Fri, 7 May 1999, 14.59.11 -0700 to ansi-epay@lists.commerce.net by tlewis@xxxxxxxx

presumably anybody could take just about any platform as a starting
point and modify it into almost any other platform (after all it is
just S.M.O.P., small matter of programming) ... however, that doesn't
make the result the same as what was started with.

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

Credit Card # encryption

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Credit Card # encryption
Newsgroups: sci.crypt
Date: Mon, 06 Aug 2001 13:29:20 GMT

Anne & Lynn Wheeler writes:

presumably anybody could take just about any platform as a starting
point and modify it into almost any other platform (after all it is
just S.M.O.P., small matter of programming) ... however, that doesn't
make the result the same as what was started with.

having been instrumental in doing the first payment gateway

http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

as well as being involved in some of the very early SET roll-outs
(& SET payment gateway)

i could claim that it would be possible to start with either payment
gateway and modify it to support X9.59 ... that would result in that
particular gateway implementation having support for x9.59 ... but