List of Archived Posts

2005 Newsgroup Postings (07/05 - 07/27)

simple question about certificate chains

Creating certs for others (without their private keys)

IBM 5100 luggable computer with APL

IBM 5100 luggable computer with APL

[newbie] Ancient version of Unix under vm/370

Globus/GSI versus Kerberos

Creating certs for others (without their private keys)

[newbie] Ancient version of Unix under vm/370

IBM's mini computers--lack thereof

IBM's mini computers--lack thereof

Cost: Teletype 33 vs. IBM Selectric Terminal (2741?)

Question about authentication protocols

IBM's mini computers--lack thereof

IBM's mini computers--lack thereof

IBM's mini computers--lack thereof

Course 2821; how this will help for CISSP exam ?

CPU time and system load

Another - Another One Bites the Dust

S/MIME Certificates from External CA

Implementation of boolean types

simd for 390(or z990)?

Old Computers and Moisture don't mix - fairly OT

Old Computers and Moisture don't mix - fairly OT

Old Computers and Moisture don't mix - fairly OT

Old Computers and Moisture don't mix - fairly OT

IBM's mini computers--lack thereof

Code density and performance?

how do i encrypt outgoing email

IBM's mini computers--lack thereof

using ssl news servers

Massive i/o

using ssl news servers

IBM's mini computers--lack thereof

Massive i/o

IBM's mini computers--lack thereof

IBM's mini computers--lack thereof

Massive i/o

public key authentication

Massive i/o

Massive i/o

capacity of largest drive

IBM's mini computers--lack thereof

public key authentication

Code density and performance?

TLAs - was summit else entirely

Digital ID

IBM's mini computers--lack thereof

Code density and performance?

Code density and performance?

IBM's mini computers--lack thereof

Cluster computing drawbacks

Cluster computing drawbacks

Cluster computing drawbacks

Barcode Email

Barcode Email

54 Processors?

simple question about certificate chains

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: simple question about certificate chains
Newsgroups: alt.computer.security,comp.security.ssh,comp.lang.java.security
Date: 05 Jul 2005 11:28:49 -0600

"Richard E. Silverman" writes:

No, browsers generally do *not* do this, for several reasons.  The
most obvious is that, since the DNS is insecure, it would be easy to
get a client to incorrectly accept a certificate by simply spoofing
its DNS traffic.  Browsers should (and generally do) match the
certificate against what the user types, nothing else -- that's the
point, to verify that you're connecting to the site you intended.
It's also why aliases don't work -- for example, suppose a site's
certificate says www.foo.com, but the server is reachable at foo.com
as well.  If you connect to https://foo.com/ the browser will give a
warning; it's up to you to decide that a certificate with the name
"www.foo.com" just as acceptable in this case.

the foo.com vis-a-vis www.foo.com was early problem ... and then they
went to wildcard certificates and wildcard browser processing ... so
that browser would get a *.foo.com ssl domain name certificate and it
would accept for all URLs ending in foo.com.

slightly related posting in sci.crypt
http://www.garlic.com/~lynn/2005l.html#19

what you typed in is matched against the site you are dealing with.

the original major application was e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the problem was that a lot of the e-commerse sites found that SSL
reduced their capacity by 80-90 percent. as a result, most sites went
to not invoking https/ssl until you hit the checkout/pay button.

the vulnerability is that one of the SSL objectives was countermeasure
against man-in-the-middle &/or impersonation attacks. if you happen to
be dealing with a bogus site w/o SSL (because nobody uses SSL until
the checkout/pay phase) ... and then you get to the checkout/pay
button ... it is highly probable that any bogus site will supply a URL
as part of the pay button (which you haven't typed in) that
corresponds to some valid SSL domain name certificate that they
actually posses.

there is actually a funny catch-22.

one of the SSL justifications was as a countermeasure to perceived
integrity problems in the domain name infrastructure.
http://www.garlic.com/~lynn/subpubkey.html#sslcert

however, when somebody applies for an SSL domain name server
certificate, the certification authority must check with the
authoritative agency for domain name ownership. this turns out to be
the same domain name infrastructure that has the integrity issues
giving rise to the requirement for SSL domain name certificates.

basically the certification authority asks for a lot of identification
information so that it can go through the complex, expensive and
error-prone process of matching the applicants supplied identification
information with the identification information on file for the
domain name owner at the domain name infrastructure.

so somewhat with the backing of the certification authority industry,
there has been a proposal to improve the integrity of the domain name
infrastructure by having domain name owners registering a public key
with the domain name infrastructure. An objective is improving the
integrity of the domain name infrastructure by having all
communication from the domain name owner be digitally signed ... which
the domain name infrastructure can authenticate with the on-file
public key (having all communication authenticated, improves the
integrity of the domain name infrastructure, which in turns improves
the integrity of the checking done by the certification authorities).

As an aside observtion ... this on-file public key
results in a certificate-less, digital signature operation.
http://www.garlic.com/~lynn/subpubkey.html#certless

The other issue for the certification authority industry, is that they
can now require that SSL domain name certificate applications also be
digitally signed. Then the certification authority can retrieve the
on-file public key from the domain name infrastructure to authenticate
the digital signature on the application. This turns an expensive,
complex, and error-prone identification process into a much less
expensive, straight-forward and more reliable authentication process.

The problem (for the CA industry) is that the real trust ruot for the
SSL domain name certificates is the integrity of the ownership
information on file with the domain name infrastructure. Improving
this trust root, in support of certifying SSL domain name certificates
... also improves the overall integrity of the domain name
infrastructure.  This, in turns minimizes the original integrity
concerns which gave rise to needing SSL domain name certificates.

The other problem (for the CA industry), if they can retrieve on-file
trusted public keys from the domain name infrastructure, it is
possible that everybody in the world could also retrieve on-file
public keys from the domain name infrastructure. One could then
imagine a variation on the SSL protocol ... where rather than using
SSL domain name certificates (for obtaining a website's public key),
the digital certificate was eliminated and the website's public key
was retrieved directly.

In fact, a highly optimized transaction might obtain the website
ip-address piggybacked with the website public key in a single message
exchange (eliminating much of the SSL protocol chatter gorp that goes
on).

In that sense, such an SSL implementation, using on-file public keys
starts to look a lot more like SSH implementation that uses on-file
public keys (eliminating the need for digital certificates, PKIs
and certification authorities all together).

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

Creating certs for others (without their private keys)

From: <lynn@garlic.com>
Newsgroups: mailing.openssl.users
Subject: Re: Creating certs for others (without their private keys)
Date: Tue, 05 Jul 2005 15:26:37 -0700

Uri wrote:

Darn, I thought I explained the problem: openssl "req" seems to
require private key of the cert requestor, which defeats the whole
idea of PKI.  Here's the excerpt of the HOWTO you're referring me
to.  It is not helpful, sorry - for the above reason (private key
necessary).
The certificate request is created like this:

openssl req -new -key privkey.pem -out cert.csr

typically the business practices of a certification authority (CA) for
issuing a digital certificate (some characteristics bound to a public
key and digitally signed) requires that the CA establish that the
requesting party has possession of the private key that corresponds to
the public key in the application.

basically a digital signature is the private key encoding of a hash of
some message or data. the recipient rehashes the same message/data,
decodes the digital signature with the indicated public key (giving the
original hash) and compares the two hashes. if they are equal, the
recipient can assume

1) the message hasn't been modified since signing
2) something you have authentication

aka, in 3-factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor

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

... where the digital signature verification implies that the
originator had access and use of the corresponding private key (w/o
having to supply the private key).

the technology is asymmetrical cryptography where there is a pair of
keys, and what one key encodes, the other key decodes.

there is a business process called public key where one of the key
pair is leabeled public and made freely available. the other of the
keypairs is labeled private, kept confidential and never divulged.

acquiring a certificate frequently involves filling out a form that
looks similar to a real certificate and digitally signing it (with
your private key) and sending it off. the certification authority then
verifies the digital signature with the public key included in the
application (this should at least indicate that the applicant has the
corresponding private key). the certification authority then verifies
(certifies) the provided information ... generates a digital
certificate (possibly in the identical format as the application) but
digitally signs it with their private key.

now once the key owner has the digital certificate, the owner (and/or
others) may be able to distribute the digital certificate all over the
world.

one of the typical problems with the PKI & certification authority
business model .... is that the party benefiting is the relying party
who uses the digital certificate to obtain a public key to verify
somebody's digital signature. Typically the person purchasing/buying
the digital certificate from a certication authority is the key owner
... not the benefitting/relying party.

in typical business process operation, the benefitting/relying party
is buying/paying for the certified information ... which tends to form
a contractual relationship between the party responsible for the
certification and the party benefiting from the certification. This
has led to situations like the federal GSA PKI project .... where GSA
has direct contracts with the certification authorities ... creating
some sort of legal obligation between the federal gov. (as a
relying/benefiting party) and the certification authorities (even when
the certification authorities are selling their digital certificates
to the key owners ... not to the benefiting/relying parties).

note that their is no actual requirement that a certification
authority needs to have evidence of the key owners private key (aka
implied by verifying a digital signature) .... it is just part of some
certification authorities business practices statement.

There was a possible opening here in the mid-90s. Certification
authorities in the early 90s, had been looking at issuing x.509
identity certificates grossly overloaded with personal
information. One of the things defined for these digital certificates
was a bit called a non-repudiation bit. In theory, this
magically turned any documents (with an attached digital signature
which could be verified with a a public key from a
non-repudiation digital certificate) into a human signature.

This is possibly because of some semantic ambiquity since human
signature and digital signature both contains the word signature.
The definition of a digital signature is that the associated
verification can imply

• message hasn't been modified
• something you have authentication

while a human signature typically implies read, understood, agrees,
approves, and/or authorizes. The supposed logic was if a relying party
could produce a message that had a digital signature and a digital
certificate w/o the non-repudiation bit ... then it was a pure
authentication operation. However, if the relying party could find and
produce a digital certificate for the same public key that happened to
have the non-repudiation bit turned on, then the digital signature
took on the additional magical properties of read, understood, agrees,
approves, and/or authorizes the contents of the message.

this logic somewhat gave rise to my observation about dual-use attack
on PKI infrastructures. A lot of public key authentication operations
involve the server sending some random data ... and the recipient
digitally signing the random data (w/o ever looking at the contents)
and returning the digital signature. The server than can
authenticate the entity by verifying the digital signature. However,
there is no implication that the entity has read, understood, agrees,
approves, and/or authorizes the random data.

An attacker just sends some valid document in lieu of random data and
is also able to produce any valid digital certificate for the
associated public key that happens to have the non-repudiation
bit set (whether or not the signing entity happened to include such a
certificate for that particular operation or not). The victim
digitally signs the supposed random data (w/o ever looking at it) and
returns the digital signature (along with a digital certificate w/o
the non-repudication bit set).  The attacker however, now has a
valid document, a valid digital signature and a valid digital
certificate with the non-repudiation bit set (obtained from any
source).

Somewhat because of the pure fantasy that being able to produce any
valid digital certificate (for a valid public key that correctly
validates the associated digital signature), with the non-repudiation
bit set, magically guarantees read, understood, agrees, approves,
and/or authorizes .... the standards definition for the
non-repudiation bit has since been significantly depreciated.

slightly related recent posts about SSL domain name certificates
http://www.garlic.com/~lynn/2005m.html#0

misc. past posts on dual-use attack
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards

IBM 5100 luggable computer with APL

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 5100 luggable computer with APL
Newsgroups: alt.folklore.computers
Date: 05 Jul 2005 17:46:32 -0600

"Phil Weldon" writes:

Anyone rember, use, or program an IBM 5100 luggable computer?

palo alto science center ...

i was at cambridge (science center)
http://www.garlic.com/~lynn/subtopic.html#545tech

and then sjr, but did periodic got to work with some palo alto people

here is specific reference:
http://www.cedmagic.com/history/ibm-pc-5100.html

i did do some work with apl &/or hone ... hone was a internal cp/cms
time-sharing service that provided world-wide support to all the
field, marketing and sales people ... primarily apl applications on
cms. starting sometime in the early to mid 70s, salesmen couldn't
submit a mainframe related order w/o it first having been run thru a
HONE application. for a time, hone had a datacenter across the back
parking lot from pasc. misc. apl and/or hone posts:
http://www.garlic.com/~lynn/subtopic.html#hone

misc past 5100 posts
http://www.garlic.com/~lynn/2000d.html#15 APL version in IBM 5100 (Was: Resurrecting the IBM 1130)
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2000g.html#46 A new "Remember when?" period happening right now
http://www.garlic.com/~lynn/2000.html#69 APL on PalmOS ???
http://www.garlic.com/~lynn/2000.html#70 APL on PalmOS ???
http://www.garlic.com/~lynn/2001b.html#45 First OS?
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2002b.html#39 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#43 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#45 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2002b.html#47 IBM 5100 [Was: First DESKTOP Unix Box?]
http://www.garlic.com/~lynn/2003b.html#42 VMFPLC2 tape format
http://www.garlic.com/~lynn/2003i.html#79 IBM 5100
http://www.garlic.com/~lynn/2003i.html#82 IBM 5100
http://www.garlic.com/~lynn/2003i.html#84 IBM 5100
http://www.garlic.com/~lynn/2003j.html#0 IBM 5100
http://www.garlic.com/~lynn/2003n.html#6 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2004c.html#8 IBM operating systems and APL
http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
http://www.garlic.com/~lynn/2005g.html#12 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005.html#44 John Titor was right? IBM 5100

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

IBM 5100 luggable computer with APL

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 5100 luggable computer with APL
Newsgroups: alt.folklore.computers
Date: 06 Jul 2005 11:48:30 -0600

CBFalconer writes:

The real introduction of luggability awaited the Osborne, improved
in the Kaypro.  The other thing that Osborne pioneered was the
bundled software package.

i thot that bundled software came much earlier ... the big change was
at gov. & legal prompting the great unbundling announcement on
6/23/69 (and starting to charge separately for software)

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

[newbie] Ancient version of Unix under vm/370

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [newbie] Ancient version of Unix under vm/370
Newsgroups: alt.folklore.computers
Date: 07 Jul 2005 11:40:04 -0600

Renaissance writes:

http://cm.bell-labs.com/cm/cs/who/dmr/otherports/ibm.pdf

Is available an ancient version of unix (licensed for hobbistic free
use) that ran as host operating system on the top of a vm/370 virtual
machine partition (obviously using the hercules emulator)?

since vm370 just provided virtual machine .... there should be little
different between real 370 machine, vm370-based 370 virtual machine or
hercules (or other) 370 virtual machine.

there was a port of unix done to a stripped down tss/370 kernel
(wasn't virtual machine interface was to higher level tss/370 kernel
functions) done specifically for at&t.

some of the other 370 ports (gold/au, aix/370) etc ... tended to be
deployed under vm370 ... not so much because of any lack in the
straight-line 370 hardware support but because most shops were
expecting normal vendor RAS support for their mainframes. the vendor
RAS support was in large part based on extensive error recording and
logging support. It was available w/vm370 and so guest operating
systems could get by w/o having to also implement all the extensive
hardware error recoding and logging (aka typical unix port could be
mapped to the 370 hardware facilities ... but it would have been a
much larger undertaking to add in all the RAS stuff ... than the
straight-forward port had been).

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

Globus/GSI versus Kerberos

From: <lynn@garlic.com>
Newsgroups: comp.protocols.kerberos
Subject: Re: Globus/GSI versus Kerberos
Date: Thu, 07 Jul 2005 11:19:07 -0700

Ken Hornstein wrote:

When I cornered one of the Globus guys and asked him point-blank the
same question, he told me that in his opinion the decision to do PKI
was really driven politically from the top, and he thought Kerberos
made a LOT more sense.

the original pk-init draft for kerberos specified certificate-less
operation
http://www.garlic.com/~lynn/subpubkey.html#certless

you basically registered a public key with kerberos in lieu of a
password and then used digital signature authentication with the
onfile public key (no PKI and/or digital certificates required).
http://www.garlic.com/~lynn/subpubkey.html#kerberos

this was basically an authentication technology upgrade w/o having to
introduce any new business processes and extraneous infrastructure
operations.

it was later that certificate-based operation was added to the
kerberos pk-init draft.

i gave a talk on this at the global grid forum #11
http://www.garlic.com/~lynn/index.html#presentation

at the meeting there was some debate on kerberos vis-a-vis radius as
an authentication & authorization business process infrastructure.

note that in addition to their having been a non-PKI, certificate-less
authentication upgrade for kerberos (using onfile public keys), there
has been a similar proposal for RADIUS; basically registering public
keys in lieu of passwords and performing digital signature
authentication with the onfile public keys.
http://www.garlic.com/~lynn/subpubkey.html#radius

Straight forward upgrade of the authentication technology w/o having
to layer on a separate cumbersome PKI business process.

Creating certs for others (without their private keys)

From: lynn@garlic.com
Newsgroups: mailing.openssl.users
Subject: Re: Creating certs for others (without their private keys)
Date: Thu, 07 Jul 2005 11:35:27 -0700

lynn@garlic.com wrote:

An attacker just sends some valid document in lieu of random data and
is also able to produce any valid digital certificate for the
associated public key that happens to have the non-repudiation bit set
(whether or not the signing entity happened to include such a
certificate for that particular operation or not).
The attacker now has a valid document, a valid digital signature and a
valid digital certificate with the non-repudiation bit set.

Somewhat because of the pure fantasy that being able to produce any
valid digital certificate (for a valid public key that correctly
validates the associated digital signature) with the non-repudiation
bit set magically guarentess read, understood, agrees, approves, and/or
authorizes .... the standards definition for the non-repudiation bit
has since been significantly depreciated.

i.e.
http://www.garlic.com/~lynn/2005m.html#1

somewhat at issue is that the standard PKI protocol involves the
originator digitally signing a message (with their private key) and
then packaging the three pieces:

• message
• digital signature
• digital certificate

in the basic authentication scenarios ... the originator never even
examines the contents of the message that is being signed (precluding
any sense of human signature, i.e. read, understood, agrees, approves,
and/or authorizes).

the other part of the problem (before non-repudiation bit was severely
depreciated in PKI certificate definition), is there is no validation
of what certificate that the originator actually appended.

even if the originator had appeneded a digital certificate w/o the
non-repudiation bit set ... they had no later proof as to what
certificate they had appended. all the attacker needs to do is being
able to obtain from anyplace in the world a digital certificate for
the same public key that happens to have the non-repudiation bit set.

in some of the pki-oriented payment protocols from the mid-90s ...
there was even suggestions that if the relying party (or attacker, or
say a merchant in an e-commerce scenario) could produce any digital
certificate for the associated public key (effectively from any
source) with the non-repudiation bit set ... then the burden of proof
(in any dispute) would be shifted from the merchant to the consumer.

[newbie] Ancient version of Unix under vm/370

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [newbie] Ancient version of Unix under vm/370
Newsgroups: alt.folklore.computers
Date: 07 Jul 2005 18:33:26 -0600

Rich Alderson writes:

I wonder if the OP is looking for the Amdahl UTS port, which IIRC
did run on top of VM.  (Vague memory from a presentation to the
systems staff at Chicago in 1982-1984 timeframe.)

why was it called "gold" before announcement ... hint, what is the
atomic acronym for gold?

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

IBM's mini computers--lack thereof

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's mini computers--lack thereof
Newsgroups: alt.folklore.computers
Date: 08 Jul 2005 10:13:59 -0600

hancock4 writes:

In the telecom group we were talking about IBM's weak offerings in the
field of mini-computers compared to PDP/DEC machines and others of
the late 1960s and early 1970s.

It seems all IBM had to offer in that range was the System/3 and 1130,
both of which were primarily batch/punch card machines, and the S/3
was business oriented.  I believe the PDP/DEC, HP, Data General, Wang,
etc. machines of that era were more real-time and terminal oriented
which made them easier to use and more popular.

Could anyone share some observations as to how IBM got left out of
that market?  My only guess is that it was swamped getting S/360+S/370
finished and working and then to make enough of them to meet high
demand.  I also sense it saw itself as a business machines maker
and not that interested in the science market, esp with small machines
that would have a small markup.

there was the 1800 and system/7 in the instrumentation world.

prior to the ibm/pc, the instrumentation division did turn out a
68k-based machine.

in the early/mid-70s, peachtree become the s/1 and found wide
deployment in instrumentation, control systems, as well as telecom
world.

there was an effort from some sectors to try and get "peachtree" to be
the core of the mainframe 3705 telecommunication unit (rather than
some flavor of a UC ... universal controller microprocessor).

there was the joke about the (os/360) mft people from kingston moving
to boca and trying to re-invent mft for the (16bit) s/1 (and called
rps) ,,,, supposedly some of them went on to work on os/2.

the rps alternative was edx that had been done by some physicists at
sjr (for lab instrumentation).

i don't have any  ship numbers for these ... but as i've noted in
the past with regard to time-sharing systems
http://www.garlic.com/~lynn/submain.html#timeshare

cp67 and vm370 saw much wider deployed numbers that many other
time-sharing systems that possible show up widely in the academic
literature. the possible conjecture is while cp67 & vm370 had much
wider deployment than better known systems from the academic
literature ... the cp67 & vm370 deployments tended to be dwarfed by
the mainframe batch system deployment numbers. however, the claim is
that vm370 on 4341 saw wider deployment than equivalent vax machines
(it was just that the ibm press was dominated by the batch system
activity).

misc. past s/1, peachtree, edx, etc posts
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#106 IBM Mainframe Model Numbers--then and now?
http://www.garlic.com/~lynn/99.html#239 IBM UC info
http://www.garlic.com/~lynn/2000b.html#66 oddly portable machines
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000b.html#87 Motorola/Intel Wars
http://www.garlic.com/~lynn/2000c.html#43 Any Series/1 fans?
http://www.garlic.com/~lynn/2000c.html#51 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000.html#71 Mainframe operating systems
http://www.garlic.com/~lynn/2001b.html#75 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#30 IBM's "VM for the PC" c.1984??
http://www.garlic.com/~lynn/2001.html#4 Sv: First video terminal?
http://www.garlic.com/~lynn/2001.html#62 California DMV
http://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
http://www.garlic.com/~lynn/2001n.html#9 NCP
http://www.garlic.com/~lynn/2001n.html#52 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#54 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002h.html#65 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002.html#45 VM and/or Linux under OS/390?????
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002l.html#16 Large Banking is the only chance for Mainframe
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#67 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002q.html#53 MVS History
http://www.garlic.com/~lynn/2003b.html#5 Card Columns
http://www.garlic.com/~lynn/2003b.html#11 Card Columns
http://www.garlic.com/~lynn/2003b.html#16 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003c.html#23 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#28 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#76 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#13 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix
http://www.garlic.com/~lynn/2003e.html#4 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003m.html#28 SR 15,15
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2004g.html#37 network history
http://www.garlic.com/~lynn/2004p.html#27 IBM 3705 and UC.5
http://www.garlic.com/~lynn/2005f.html#56 1401-S, 1470 "last gasp" computers?
http://www.garlic.com/~lynn/2005.html#17 Amusing acronym

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

IBM's mini computers--lack thereof

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's mini computers--lack thereof
Newsgroups: alt.folklore.computers
Date: 08 Jul 2005 10:30:46 -0600

Mike Ross writes:

I could be wrong, but I thought the main CPU was a larger (360/65?
Larger still?) box, with multiple 360/50s as front-ends...

from melinda's source ...
http://www.princeton.edu/~melinda

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

story trying to get a spare 360/50 to modify for virtual memory
... but all the 360/50s were going to FAA and cambridge had to settle
for 360/40 to modify for virtual memory.

quote from melinda's paper
http://www.garlic.com/~lynn/2002b.html#7 Microcode?

random past 9020 postings:
http://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/2001e.html#13 High Level Language Systems was Re: computer books/authors (Re: FA:
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#45 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#15 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#17 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2001i.html#14 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#15 IBM 9020 FAA/ATC Systems from 1960's
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#13 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2001k.html#65 SMP idea for the future
http://www.garlic.com/~lynn/2001l.html#5 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2001n.html#53 A request for historical information for a computer education project
http://www.garlic.com/~lynn/2001n.html#62 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#32 First DESKTOP Unix Box?
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002e.html#5 What goes into a 3090?
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002f.html#29 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#42 Blade architectures
http://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002g.html#2 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#19 PowerPC Mainframe?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#14 index searching
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2002i.html#79 Fw: HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002l.html#10 What is microcode?
http://www.garlic.com/~lynn/2002l.html#39 Moore law
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002o.html#25 Early computer games
http://www.garlic.com/~lynn/2002o.html#28 TPF
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#59 AMP  vs  SMP
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003c.html#30 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#7 Low-end processors (again)
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#50 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#52 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#48 InfiniBand Group Sharply, Evenly Divided
http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
http://www.garlic.com/~lynn/2003j.html#58 atomic memory-operation question
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003m.html#4 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2003m.html#37 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003m.html#42 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2003o.html#52 Virtual Machine Concept
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2003p.html#40 virtual-machine theory
http://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
http://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
http://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#3 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#12 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004e.html#44 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#1 Saturation Design Point
http://www.garlic.com/~lynn/2004.html#7 Dyadic
http://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#10 Complex Instructions
http://www.garlic.com/~lynn/2004l.html#42 Acient FAA computers???
http://www.garlic.com/~lynn/2004n.html#45 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
http://www.garlic.com/~lynn/2005c.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns

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

Cost: Teletype 33 vs. IBM Selectric Terminal (2741?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cost: Teletype 33 vs. IBM Selectric Terminal (2741?)
Newsgroups: alt.folklore.computers
Date: 08 Jul 2005 10:39:52 -0600

hancock4 writes:

The other was the IBM Selectric Terminal, IIRC the 2741.  This ran
faster at 15 chars/sec, produced a much nicer image, could be used
on specialty machines like APL, and was a lot quieter.  However, AFAIK
it had no paper tape or other offline storage capability.  I believe it
could only be used on IBM systems.  I believe it was more used as a
specific business terminal--that is, for a specific application (ie
a reservations desk) as opposed to general purpose work.  It could also
be used offline as a standard office typewriter, a nice function.
I have no idea what it cost to rent or buy.

possibly the 2740 had paper tape option? ... the 1052 did have
papertape option. 1052, 2740, and 2741 all used the selectric typeball
mechanism. i have vaque memorys being told the 1052 was designed for
heavier duty cycle than 2741.

quicky web search for 1052, 2740, 2741, ...
http://www.yelavich.com/history/ev197001.htm
http://www.beagle-ears.com/lars/engineer/comphist/ibm_nos.htm
http://portal.acm.org/citation.cfm?id=356563

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

Question about authentication protocols

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Question about authentication protocols
Newsgroups: sci.crypt
Date: 08 Jul 2005 12:25:30 -0600

Peter Seibel writes:

One page 54 of Schnier's _Applied Cryptography_ he presents a naive
authentication protocol based on public key crpto. It goes like this:

(1) Host sends Alice a random string.

(2) Alice encrypts the string with her private key and sends it back
to the host, along with her name.

(3) Host looks up Alice's public key in its database and decrypts
the message using that public key.

(4) If the decrypted string matches what the host sent Alice in the
first place, the host allows Alice access to the system.

He then points out that this protocol is problematic because Alice
shouldn't be encrypting arbitrary strings with her private key lest
she open herself up to various attacks which he describes in Section
19.3. He then gives an outline of more sophisticated protocols for
proving identity that involve Alice performing various computations
based on random numbers that she generates and her private
key. (The actual protocols are described in Section 21.1.)

However in 19.3 when he discusses the attacks that are possible if
Alice encrypts arbitrary strings with her private key he closes with
this Moral: "Never use RSA to sign and random document presented to
you by a stranger. Always use a one-way hash function first."

So why can't the naive protocol be fixed by simply following that
advice and having Alice hash the random string and encrypt the
hash. In other words the patched protocol (with changes in ALL CAPS)
goes like this:

(1) Host sends Alice a random string.

(2) Alice HASHES THE STRING and encrypts the HASH with her private
key and sends it back to the host, along with her name.

(3) Host looks up Alice's public key in its database and decrypts
the message using that public key.

(4) If the decrypted string matches THE HASH OF what the host sent
Alice in the first place, the host allows Alice access to the
system.

i think the examples were to take the student through the various thot
processes.

so standard digital signature definition is using private key to
encode hash of message. the recipient then calculates the hash of the
string, decodes the digital signature with the public key and compares
the two hashs. if they are equal, the recipient assumes

1) message hasn't been changed in transit
2) something you have authentication (aka originator has access
   and use of the corresponding "private" key).

discussion of the digital signature standard:
http://csrc.nist.gov/cryptval/dss.htm

lots of posts on the 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

and other posts on certificate-less public key operations
http://www.garlic.com/~lynn/subpubkey.html#certless

there can be an issue of the dual-use attack ... there has sometimes
been some possibly semantic confusion with the term digital
signature and human signature because they both contain the word
signature.

human signature usually includes the connotation of read,
undertstands, agrees, approves, and/or authorizes.

as in your description, the party, being authenticated, assumes that
they are getting a random string and rarely, if ever, examines what is
being digitally signed.

in various scenarios, there have been efforts to promote digital
signatures to the status of human signatures. a dual-use attack on a
private key used for both authentication infrastructures as well as
such human signature operations ... is for the attacker to
substitute a valid document in lieu of random bit string.

this was exaserbated in the pki/certificate standards world by the
introduction of the non-repudiation bit as part of the certification
standard. if a relying party could find any certificate, anyplace in
the world (for the signer's public key) containing the non-repudiation
bit ... then they could claim that the existance of that digital
ceritificate (for the originator's public key containing the
non-repudiation bit) was proof that the originator had read,
understood, agrees, approves, and/or authorizes what had been
digitally signed. in some of the PKI-related payment protocols from
the 90s, this implied that if a relying-party could produce a digital
certificate containing the signer's public key & the non-repudiation
bit ... then in any dispute, it would shift the burden of proof from
the relying party to the digitally signing party.

some recent posts on the subject
http://www.garlic.com/~lynn/2005l.html#18 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#5 Globus/GSI versus Kerberos
http://www.garlic.com/~lynn/2005m.html#6 Creating certs for others (without their private keys)

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

IBM's mini computers--lack thereof

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's mini computers--lack thereof
Newsgroups: alt.folklore.computers
Date: 08 Jul 2005 16:54:02 -0600

Peter Flass writes:

IBM didn't (I believe) try to compete with the VAX, although it had
several machines that could have. The RS-6000 machines seemd to be
aimed at the engineering/scientific market, and the AS/400's at
commercial. Now of course, the're the same CPU.  Who now competes with
RS-6000? Sun, HP, anyone else?

4341 w/vm was in the same market segment and time-frame as vax ...
and i believe 4341/vm had bigger install base ... although as posted
before ... there were several corporate issues that could have been
interpreted as resulting in lost sales to vax.

part of this was that endicott's 4341 also was very strong competitor
to pok's 3031 ... and as such there was some internal corporate
political maneuvering.

rs6000 was much later.

risc/801/romp was going to be a display writer follow-on in the early
80s by the office products division.  it was going to be CPr based
with lots of implementation in pl.8. when that was cancelted, it was
decided to quickly retarget the platform to the unix workstation
market. somewhat to conserve skills .... a pl.8-based project was put
together called the virtual resource manager .... that sort of
provided a high-level abstract virtual machine interface (and
implemented in pl.8). Then the vendor that had done the at&t port
to ibm/pc for pc/ix was hired to do a similar port to the vrm
interface. this became pc/rt and aix.

follow-on to pcrt/romp was rs6000/rios/power, the vrm was mostly
eliminated and aixv3 was built to the rios chip interface. there is
paper weight on my desk that has six chips with the legend: POWER
architecture, 150 million OPS, 60 millon FLOPS, 7 million transistors.
misc. 801/romp/rios postings
http://www.garlic.com/~lynn/subtopic.html#801

the executive that we reported to while we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

sample, specific post
http://www.garlic.com/~lynn/95.html#13

left to head-up somerset ... the joint ibm, motorola, apple, et al
effort for power/pc. differences between rios/power and power/pc
.... rios/power was designed for flat out single processor thruput
... tending to multi-chip implementation and no provisions for cache
coherency and/or multiprocessor support. the power/pc was going to
single-chip implementation with support for multiprocessor cache
coherency. it was the power/pc line of chips that show up in apple,
as/400, and some flavors of rs/6000 ... while other flavors of rs/6000
were pure rios/power implementation (including the original rs/6000).

i have some old memories of arguments going on between austin and
rochester over doing power/pc 65th bit implementation. unix/apple
world just needed 64bit addressing. rochester/as400 was looking for a
65th bit tag line ... helping supporting their memory architecture.

post posting with some vax (us & worldwide) ship numbers
http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

part of the issue was that the price/performance during vax & 4341
time-frame seemed to have broken some threshhold. You started to see
customer orders for 4341s that were in the hundreds ... quite a few
that were single orders for large hundreds of 4341s. this really
didn't carry-over to the 4381 (4341 follow-on), since by that time,
you started to see that market being taken over by large PCs and
workstations.

specific post:
http://www.garlic.com/~lynn/2001m.html#15 departmental servers

other past posts regarding the departmental computing/server market
http://www.garlic.com/~lynn/94.html#6 link indexes first
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
http://www.garlic.com/~lynn/2001m.html#44 Call for folklore - was Re: So it's cyclical.
http://www.garlic.com/~lynn/2001m.html#56 Contiguous file system
http://www.garlic.com/~lynn/2001n.html#15 Replace SNA communication to host with something else
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#0 Did Intel Bite Off More Than It Can Chew?
http://www.garlic.com/~lynn/2002c.html#27 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002e.html#2 IBM's "old" boss speaks (was "new")
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002e.html#61 Computers in Science Fiction
http://www.garlic.com/~lynn/2002e.html#74 Computers in Science Fiction
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#7 Blade architectures
http://www.garlic.com/~lynn/2002f.html#48 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2002g.html#19 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2002i.html#29 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#7 HONE, ****, misc
http://www.garlic.com/~lynn/2002j.html#34 ...killer PC's
http://www.garlic.com/~lynn/2002j.html#66 vm marketing (cross post)
http://www.garlic.com/~lynn/2002k.html#18 Unbelievable
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002m.html#9 DOS history question
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002p.html#6 unix permissions
http://www.garlic.com/~lynn/2002p.html#59 AMP  vs  SMP
http://www.garlic.com/~lynn/2003c.html#14 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#17 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#71 Tubes in IBM 1620?
http://www.garlic.com/~lynn/2003d.html#37 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#61 Another light on the map going out
http://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix
http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
http://www.garlic.com/~lynn/2003f.html#46 Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#50 Alpha performance, why?
http://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
http://www.garlic.com/~lynn/2003j.html#60 Big Ideas, where are they now?
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003n.html#46 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2003o.html#13 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#24 Tools -vs- Utility
http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004g.html#23 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004.html#1 Saturation Design Point
http://www.garlic.com/~lynn/2004.html#7 Dyadic
http://www.garlic.com/~lynn/2004.html#46 DE-skilling was Re: ServerPak Install via QuickLoad Product
http://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Re: Vintage computers are better
http://www.garlic.com/~lynn/2004k.html#23 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
http://www.garlic.com/~lynn/2004l.html#10 Complex Instructions
http://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#71 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#49 Secure design
http://www.garlic.com/~lynn/2005f.html#30 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#35 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005.html#43 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005m.html#9 IBM's mini computers--lack thereof

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

IBM's mini computers--lack thereof

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's mini computers--lack thereof
Newsgroups: alt.folklore.computers
Date: 09 Jul 2005 09:46:13 -0600

Anne & Lynn Wheeler writes:

left to head-up somerset ... the joint ibm, motorola, apple, et al
effort for power/pc. differences between rios/power and power/pc
.... rios/power was designed for flat out single processor thruput
... tending to multi-chip implementation and no provisions for cache
coherency and/or multiprocessor support. the power/pc was going to
single-chip implementation with support for multiprocessor cache
coherency. it was the power/pc line of chips that show up in apple,
as/400, and some flavors of rs/6000 ... while other flavors of
rs/6000 were pure rios/power implementation (including the original
rs/6000).

oh, almost forgot, and in this time frame, wang and others were
convinced to convert to the processor also. bull also rebranded the
6000.

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

IBM's mini computers--lack thereof

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's mini computers--lack thereof
Newsgroups: alt.folklore.computers
Date: 10 Jul 2005 14:36:19 -0600

"David Wade" writes:

No one has mentioned the Series/1, wasn't this IBM's "mini" after
the 1130 was dropped. Trouble is the Series/1 was more a cut down
mainframe that a fully fledged mini...

various recent posts mentioning series/1 &/or peachtree
http://www.garlic.com/~lynn/2005d.html#1 Self restarting property of RTOS-How it works?
http://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#56 1401-S, 1470 "last gasp" computers?
http://www.garlic.com/~lynn/2005h.html#5 Single System Image questions
http://www.garlic.com/~lynn/2005.html#17 Amusing acronym
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005m.html#8 IBM's mini computers--lack thereof

there were some people that attempted to get peachtree for the core
that became the 3705 mainframe telecommunication controller.

i had some interest in this area ... having worked on a clone
mainframe telecommunication controller as an undergraduate (and
some write-up blaming the project for starting clone controller
business)
http://www.garlic.com/~lynn/subtopic.html#360pcm

and then later tried to expand and productize a s/1-based implementation
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)

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

Course 2821; how this will help for CISSP exam ?

From: <lynn@garlic.com>
Newsgroups: microsoft.public.certification.networking
Subject: Re: Course 2821; how this will help for CISSP exam ?
Date: Tue, 12 Jul 2005 19:28:39 -0700

davidxq wrote:

i think this course can teach you the basic theory of PKI, but it cannot
overlap the CISSP related topic.

the technology is asymmetric key cryptography ... basically what one
of a keypair can encode, the other key decodes (in contrast to
symmetric key cryptography where the same key is used for encoding and
decoding).

there is a business process called public key .... where one key, of a
keypair is identified as public and freely distributed, the other of
the keypair is identified as private, kept confidential and never
divulged.

there is a business process defined digital signature .... where the
origin calculates the hash of a message/document and then encodes the
hash with the private key ... and transmits the message/document with
the appended digital signature. the recipient recalculates the hash of
the message/document, decodes the digital signature with the public
key and compares the two hashes. if they are equal, then it is
assumed:

1) the message/document hasn't changed since the digital signature
2) something you have authentication, aka the originator has access
and use of the corresponding private key.

This can have tremendous advantage over shared-secrets likes
pins/passwords and/or other something you know static data
authentication.

In the 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

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

the typical shared-secret
http://www.garlic.com/~lynn/subintegrity.html#secret

has short-coming that it can both originate and authenticate an
operation ... i.e. entities with access to the authentication
information can also use it to impersonate. partially as a result, the
standard security recommendations is that a unique shared-secret is
required for every security domain (so individuals in one security
domain can't take the information and impersonate you in a different
security domain). There is also the threat/vulnerability of
evesdropping on the entry of the shared-secret information for
impersonation and fraud.

It is possible to substitute the registration of public keys in lieu
of shared-secrets. Public keys have the advantage that they can only
be used to authenticate, they can't be used to impersonate. Also,
evesdropping on digital signatures doesn't provide much benefit since
the it is the private key (that is never divulged) that is used to
originate the authentication information.
http://www.garlic.com/~lynn/subpubkey.html#certless
http://www.garlic.com/~lynn/subpubkey.html#radius
http://www.garlic.com/~lynn/subpubkey.html#kerberos

Basically, you build up a repository of trusted public keys of
entities that you have dealings with for authentication purposes.

There has something been called PKI, certification authorities, and
digital certificates designed to meet the offline email paradigm of
the early 80s (somewhat anlogous the "letters of credit" from the
sailing ship days). The reipient dials their local (electronic)
postoffice, exchanges email and then hangs up. They now may be faced
with first-time communication with total stranger and they have no
local and/or online capability of determining any information
regarding the stranger.

In this first time communication with total stranger, the trusted
public key repository has been extended. There are certification
authories that certify information and create digitally signed digital
certificates containing an entities public key and some information.
The recipient now gets an email, the digital signature of the email,
and a digital certificate. They have preloaded their trusted public
key repository with some number of public keys belonging to
certification authorities. Rather than directly validated a sender's
digital signature, they validate the certification authorities digital
signature (using a public key from their local trusted public key
repository) on the digital certificate. If that digital signature
validates, then they use the public key from the digital certificate
to validate the actual digital signature on the message.

In the early 90s, there were these things, x.509 identity certificates
that were starting to be overloaded with personal information (the
idea being that a recipient find at least one piece of personal
information useful when first time communication with a total stranger
is involved, and therefor the certificate serving a useful
purpose). The business model was sort of do away with all established
business relationships and substitute spontaneous interaction with
total strangers. For instance, rather than depositoring large sums of
money in a financial institution with which you have an established
account ... you pick out a total stranger with which to give large
sumes of money. The exchange of x.509 identity certificates would be
sufficient to provide safety and security for your money. This also
had the characteristic that all transactions (even the most simplest
of authentication operations) were being turned into heavy duty
identification operations.

In the mid-90s, some institutions were coming to the realization that
x.509 identity certificates, overloaded with excessive personal
information, represented significant liability and privacy issues. As
a result, you saw some financial institutions retrenching to
relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

which basically contained a public key and some form of database index
where the actual information was stored. However, it is trivial to
demonstrate that such relying-party-only certificates are redundant
and superfluous:

1) first they violate the design point for certificates ... providing
information that can be used in first time communication with total
stranger

2) if the relying party already has all the information about an
entity, then they have no need for a stale, static digital certificate
that contains even less information.

This was exasherbated in the mid-90s by trying to apply stale, static,
redundant and superfluous relying-party-only digital certificates to
payment protocols. The typical iso8583 payment message is on the order
of 60-80 bytes. The PKI overhead of even relying-party-only stale,
static, redundant and superfluous digital certificates were on the
order of 4k-12k bytes. The stale, static, redundant and superfluous
digital certificate attached to every payment message would have
represented a payload bloat of one hundred times.

CPU time and system load

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CPU time and system load
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: 13 Jul 2005 10:06:09 -0600

mike.meiring@ibm-main.lst (Mike Meiring) writes:

Should be about the same , but in some cases PR/SM (Lpar) overhead
can cause increase in TCB times. On a lightly loaded system the
capture ratio would typically drop, meaning that operating system is
incurring relatively more 'overhead' ('Low utilization effects'
(LUE) coming into play).

in the pr/sm, lpar, etc ... it tends to be the ratio of instructions
that involve overhead ... to all instructions. in low utilization
environment, a large part of the execution tends to be in the kernel,
which has a higher ratio of instructions w/overhead. A BR15 loop could
be considered notorious for instruction that has no hypervisor
overhead.

the univ. that i was at ... got cp67 installed the last week in
jan. 68 ... and i got to attend the march '68 share meeting in houston
for the cp67 announcement. then at the aug. '68 share meeting in
boston ... i got to present a talk on mft14 enhancements as well as
cp67 enhancements.

the workload at the univ. was lots of short jobs (before watfor) and
was primarily job scheduler. i had done a lot of i/o tuning on mft14
to make thruput of this job mix nearly three times faster (12.7secs
per 3-step job vis-a-vis over 30 seconds elapsed time for
out-of-the-box mft14) essentially the same number of instructions
executing in close to 1/3rd time ... because of drastically optimized
disk and i/o performance).

I had also rewritten a lot of the cp67 kernel between jan. and the
boston share meeting to drastically reduce hypervisor overhead for
high overhead instructions/operations.

In the boston talk, i have the ratio of elapsed time w/hypervisor to
elasped w/o hypervisor for mft14 job stream. Using these statistics, a
normal, out-of-the-box mft14 looked much better running in a
hypervisor environment. improving basic elapsed time by a factor of
nearly 3 times by optimizing i/o made the hypervisor ratio much
worse. Basically there was no increase in hypervisor overhead time for
i/o wait. Drastically cutting i/o wait made the hypervisor overhead
time ratio much worse (amount of overhead stayed the same but occured
in much shorter elapsed time).

The obtimized MFT14 jobstream ran in 322sec elapsed time on bare
machine and in 856sec elapsed time under unmodified cp67 (534secs of
cp67 hypervisor cpu overhead). With a little bit of work part time (I
was still undergraduate and also responsible for the MFT14 production
system), I got this reduced to 435secs elapsed time (113secs of cp67
hypervisor cpu overhead vis-a-vis the original 534 seconds of cp67 cpu
overhead).

part of talk from boston '68 share presentation
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

a couple overheadsfrom above:

                     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

.... footnote for above overhead

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.

.... summary of some of the CP/67 optimization work during the
spring and summer of '68

                            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 | http://www.garlic.com/~lynn/

Another - Another One Bites the Dust

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Another - Another One Bites the Dust
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: 13 Jul 2005 10:18:40 -0600

wball@ibm-main.lst (William Ball) writes:

You're making a leap there that -I'm- certainly not ready to
make. Speed isn't everything, never has been.

If you want to play games or have application that you don't really
care about when it gets done and a lot of times in accurate results
and only has 1 or 2 users, you -might- be able to live with putting
it on a Unix platform.

However, IMHO, the RAS -really- stinks.

long ago and far away .... the dasd engineering lab (bldg 14) and dasd
product test lab (bldg 15) had these "testcells" where tested stuff
under development. that had some number of processes that were
scheduled for stand-alone time with a testcell (they had several 2914
channel switches for connecting a specific testcell to a specific
processor).
http://www.garlic.com/~lynn/subtopic.html#disk

they had tried running a processor with MVS and a single testcell ...
but at the time, MVS had a 15min mean-time-between-failure trying to
run a single testcell.

I undertook to rewrite IOS (making it bullet proof) so that 6-12
testcells could be operated concurrently in an operating system
environment. I then wrote an internal corporate only report about the
effort ... unfortunately I happened to mention the base MVS case of
15min MTBF ... and the POK RAS guys attempted to really bust my chops
over the mention.

That was not too long after my wife served her stint in POK in
charge of loosely-coupled architecture ... while there she had
come up with peer-coupled shared data architecture
http://www.garlic.com/~lynn/submain.html#shareddata

but was meeting with little success in seeing it adopted (until much
later in sysplex time-frame ... except for some work by the IMS
hot-standby people).

somewhat based on experience ... we started the ha/cmp project
in the late '80s
http://www.garlic.com/~lynn/subtopic.html#hacmp
one specific mention
http://www.garlic.com/~lynn/95.html#13

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

S/MIME Certificates from External CA

From: <lynn@garlic.com>
Newsgroups: microsoft.public.biztalk.general,microsoft.public.windows.server.security
Subject: Re: S/MIME Certificates from External CA
Date: Wed, 13 Jul 2005 18:18:57 -0700

Jeff Lynch wrote:

Forgive my ignorance of digital certificates. So far I've always
used HTTPS/SSL server-side certificates but not (S/MIME - PKI) in
BTS2004 running on Win2K3.  I know that BizTalk Server 2004 can
use a digital certificate for signing and encryption (S/MIME) of
outbound documents from a Windows Server acting as a CA but can it
use a certificate from an external CA such as VeriSign?  If so,
how is the certificate "requested" from the external CA and what
type of certificate is required?

the technology is asymmetric cryptography ... what one key (of a
keypair) encodes, the other key (of the keypair) decodes. This is in
contrast to symmetric key cryptography where the same key is used to
both encode and decocde.

there is a business process called public key ... where one key (of a
keypair) is labeled public and is freely distributed. the other key
(of the keypair) is labeled private and is kept confidential and never
divulged.

there is a business process called digital signatures for doing
something you have authentication; basically the hash of a
message/document is computed and encode with the proviate key. the
message/document and the digital signature are transmitted. the
recipient recalculates the hash on the message/document and decodes
the digital signature with the public key and compares the two
hashes. if the two hashes are the same, then the recipient assumes

1) the message/document has not changed since being signed 2)
something you have authentication; the originator has access and use
of the corresponding private key.

public keys can be registered in lieu of pins, passwords,
shared-secrets, etc as part of authentication protocols ... aka
http://www.garlic.com/~lynn/subpubkey.html#certless
http://www.garlic.com/~lynn/subpubkey.html#radius
http://www.garlic.com/~lynn/subpubkey.html#kerberos

PKIs, certification authorities, and digital certificates were created
to address the offline email type scenario from the early 80 (and
somewhat analogous to the "letters of credit" paradigm from the
sailing ship days). The recipient dials their local (electronic) post
office, exchanges email, and hangs up. at this point they may be faced
with first time communication from a total stranger and they have no
local &/or other means of establishing any information about the email
sender.

The infrastructure adds the public keys of trusted certification
authorities to the recipients repository of trusted public keys.
Individuals supply their public key and other information to a
certification authority and get back a digital certificate that
includes the public key, the supplied inoformation and digitally
signed by the certification authority. Now, when sending first time
email to a total stranger, the originator digitally signs the email
and transmits the 1) email, 2) the digital signature, and the 3)
digital certificate.  The recipient validates the certification
authorities digital signature (on the digital certificate) using the
corresponding public key from their repository of trusted public
keys. If the digital certificate appears to be valid, then they
validate the digital signature on the mail using the public key from
the digital certificate. They now can interpret the email using what
every useful certified information from the digital certificate.

Basically, one might consider an "external certification authority"
...  as an authority that you haven't yet loaded their public key into
your repository of trusted public keys.

SSL/HTTPS domain name server certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

were designed for

1) encrypted channel as countermeasure to evesdropping at any point in
the communication
2) is the webserver you are talking to really the webserver you think
you are talking to

Part of this was because of perceived integrity weaknesses in the
domain name infrastructure. A webserver address is typed into the
browser. the webserver sends back a digital certificate .... that has
been signed by a certification authority whos public key has been
preloaded into the browsers repository of trusted public keys. The
browser validates the digital signature on the digital certificate.
They then compare the domain name in the digital certificate with the
typed in domain name. Supposedly if they are the same ... you may be
talking to the webserver you think you are talking about

The browser now can generate a random session key and encode it with
the server's public key (from the digital certificate) and send it
back to the server. If this is the correct server, then the server
will have the corresponding private key and can decode the encrypted
random session key from the browser. From then on, the server and the
browser can exchange encrypted information using the random session
key (if it isn't the correct server, the server won't have access to
the correct private key and won't be able to decode the random session
key sent by the browser).

when this was originally be worked out
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the objective was that the URL supplied by the end-user started out
using HTTPS. In the e-commerce world ... some number of servers found
that using HTTPS cut thruput by something like 80-90percent compared
to plain HTTP. So you started seeing ecommerce sites using simple HTTP
for all of the shopping experience and saving HTTPS when the user went
to hit the pay/checkout button. The problem is that if the user was at
a spoofed site during the HTTP portion ... than any fraudulent site
would likely supply a URL with the pay/checkout button that
corresponded to a URL in some valid digital certificate that they had
(defeating the objective of making sure the server you thot you were
talking to was actually the server you were talking to).

there is something of a catch-22 in this. A lot of certification
authorities are purely in the business of checking on the validity of
the information they are certifying ... they aren't actually the
authoritative agency for the actual information. In the SSL domain
name certificate scenario, the certification authorities ask from some
amount of identiification information from the certificate applicant.
They then contact the authoritative agency for domain name ownership
and cross-check the applicant's supplied identification information
with the identification information on file with the domain name
infrastructure as to the domain name ownership. Note however, this
domain name infrastructure which is the trust-root for things related
to domain names ... is the same domain name infrastructure which is
believe to have integrity issues that give rise to requirement for SSL
domain name certificates.

So a proposal, somewhat supported by the SSL domain name certification
authority industry ... is that domain name owners register their
public key with the domain name infrastructure. Then all future
communication with the domain name infrastructure is digitally signed
... which the domain name infrastructure can validate with the on-file
public key (note: a certificate-less operation). This communication
validation is thought to help eliminate some integrity issues.

For the certification authority industry, they now can also request
that SSL domain name certificate applications also be digital signed.
They now can change from an expensive, error-prone, and complex
identification process to a much simple and cheaper authentication
process (by retrieving the onfile public key from the domain name
infrastructure and validating the digital signature).

The catch-22s are 1) improving the integrity of the trust-root for
domain name ownership also lowers the requirement for SSL domain name
certificates because of concerns about domain name infrastructure
integrity and 2) if the certification authority industry can retrieve
onfile public keys from the domain name infrastructure to validate who
they are communicating with ... it is possible that the rest of the
world could also ... eliminating any need for having SSL domain name
server certificates.

One could imagine a simplified and optimized SSL protocol, where the
client retrieves the ip-address and the associated public key from the
domain name infrastructure in a single, existing exchange. They could
then piggyback the randomly generated session key encoded with the
servers public key on the initial contact with the server.

Another issue was some trend in the early 90s to overload the x.509
identity certificates with large amounts of personal information
... in hopes that future "strangers" (relying parties) would find
something useful/meaningful when receiving first time communication
(since CAs couldn't necessarily predict the context that future
relying parties might be interested in).

In the mid-90s, there started to be some realization that x.509
identity certificates, grossly overloaded with personal information
represented significant privacy and liability issues. As a result, you
found some institutions retrenching to relying-party-only
certificates ...  basically a public key and some sort of database
lookup index (where all the real information about an individual was
stored). However, it was trivial to show that such relying-party-only
certificates were redundant and superfluous ... aka 1) they
violated the premise of supplying information for first-time
communication between strangers and 2) if the relying party
(recipient) already had a superset of the information found in a
digital certificate (including the originator's public key) ... then
it was redundant and superfluous for the originator to be
constantly sending a copy of the certificate back to the relying party
on every communication.

The other issue was that there were attempts to try and have x.509
identity certificates attached to all digitally signed documents and
messages. This basically resulted in causing a large amount of
confusion about the differences between authentication and
identification ... and would have effectively turned all electronic
operations ... even the most trivial authentication operations
.... into heavyweight identification operations.

Implementation of boolean types

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Implementation of boolean types.
Newsgroups: comp.databases.theory
Date: 14 Jul 2005 07:38:41 -0600

Jonathan Leffler writes:

SQL-1999 and SQL-2003 both have a BOOLEAN type, with recognized values
TRUE, FALSE and UNKNOWN.  I'm not clear whether NULL is equivalent to
UNKNOWN or not; I've not scrutinized the weasel-words carefully enough.

old 3-value logic posting
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
http://www.garlic.com/~lynn/2004l.html#75 NULL

reference to Dec. '92, article by CJ Date

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

simd for 390(or z990)?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: simd for 390(or z990)?
Newsgroups: comp.arch
Date: 15 Jul 2005 12:56:50 -0600

"Michel Hack" writes:

Well, that's the point: *was*.  The VF died with the bipolar boxes
(3090 was the last one, in 1992).  It is now officially dead, in
that the opcode space has been re-used for new 64-bit instructions
in z/Series machines.

i heard somebody once trying to make the case that 3090 VF was purely
a marketing offering ... that 3090 scalar had been so optimized that
it could drive memory at nearly saturation ... and therefor there was
little additional thruput gained from using VF.

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

Old Computers and Moisture don't mix - fairly OT

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers and Moisture don't mix - fairly  OT
Newsgroups: alt.folklore.computers
Date: 16 Jul 2005 09:20:34 -0600

forbin@dev.nul (Colonel Forbin) writes:

What I meant by the raised floor was a raised computer room floor,
which is installed over the subfloor.  If the problem isn't too bad,
the airflow might be sufficient to keep things liveable, but it's a
kludge in a situation like this, and corrosion under the raised
floor, including its superstructure, will remain a problem.  Hence,
this would be a temporary solution if it was intended to relocate to
a more suitable building.

santa teresa labs ... coyote valley ... south san jose ... was built
in large meadow at base of some hills. the datacenter is sunk in the
middle of complex of towers. it turns out that one of the things that
made the meadow, was run-off from the hills (especially) during the
rainy season.  for the first year or so ... the datacenter had
flooding problems.

... topic drift ... santa teresa labs was originally going to be
called coyote labs ... using a convention of naming after the nearest
post office. the week before coyote labs was to open (I think the
Smithsonian air&space museum and coyote labs were opening the same
week), i happened to be in DC. That week, there was some
demonstrations on the capitol steps (that made the national press) by
an organisation of working ladies from san francisco ... which is
believed to have led to the decision to quickly change the name of the
lab from coyote to santa teresa (closest cross street).

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

Old Computers and Moisture don't mix - fairly OT

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers and Moisture don't mix - fairly  OT
Newsgroups: alt.folklore.computers
Date: 16 Jul 2005 09:47:59 -0600

Anne & Lynn Wheeler writes:

santa teresa labs ... coyote valley ... south san jose ... was built
in large meadow at base of some hills. the datacenter is sunk in the
middle of complex of towers. it turns out that one of the things that
made the meadow, was run-off from the hills (especially) during the
rainy season.  for the first year or so ... the datacenter had
flooding problems.

two of the biggest datacenters that i've been in ... boeing renton in
the late 60s ... when there were nearly constantly flow of 360/65s
staged in the halls waiting for installation ... and POK in the early
70s. however, there have been rumors that the datacenter described in
chapter nineteen of "Boyd, The fighter pilot who changed the art of
war" (by Robert Coram; Little, Brown) might have been larger (it
mentions $2.5b windfall for IBM).

misc. past boyd refs:
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

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

Old Computers and Moisture don't mix - fairly OT

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers and Moisture don't mix - fairly  OT
Newsgroups: alt.folklore.computers
Date: 16 Jul 2005 10:03:09 -0600

Anne & Lynn Wheeler writes:

two of the biggest datacenters that i've been in ... boeing renton in
the late 60s ... when there were nearly constantly flow of 360/65s
staged in the halls waiting for installation ... and POK in the early
70s. however, there have been rumors that the datacenter described in
chapter nineteen of "Boyd, The fighter pilot who changed the art of
war" (by Robert Coram; Little, Brown) might have been larger (it
mentions $2.5b windfall for IBM).

misc. past boyd refs:
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

maybe the $2.5b was used to help offset the amount spent on FS ...
which was canceled w/o ever being announced
http://www.garlic.com/~lynn/submain.html#futuresys

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

Old Computers and Moisture don't mix - fairly OT

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old Computers and Moisture don't mix - fairly  OT
Newsgroups: alt.folklore.computers
Date: 16 Jul 2005 11:20:09 -0600

Anne & Lynn Wheeler writes:

two of the biggest datacenters that i've been in ... boeing renton in
the late 60s ... when there were nearly constantly flow of 360/65s
staged in the halls waiting for installation ... and POK in the early
70s. however, there have been rumors that the datacenter described in
chapter nineteen of "Boyd, The fighter pilot who changed the art of
war" (by Robert Coram; Little, Brown) might have been larger (it
mentions $2.5b windfall for IBM).

misc. past boyd refs:
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

I can imagine the place also having water problems ... large
underground bunker, extremely high humidity environment and rainy
season that could be pretty extreme.

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

IBM's mini computers--lack thereof

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's mini computers--lack thereof
Newsgroups: alt.folklore.computers
Date: 17 Jul 2005 08:05:10 -0600

"Rupert Pigott" writes:

I saw a few VAXen running 30+ spindles fairly well. They seemed
to get the job done OK. Worked on a couple of Alpha servers that
ran 100+ spindles, they were waiting on the drives, the network
or the users most of the time. DEC got there in the end - only
to be HPAQ'd :S

circa 1980 ... would periodically visit an installation in the bay
area and had a pair of loosely-coupled 370/158 with 300+ 3330 drives
... not particularly large operation from the processor standpoint
(158 originally announce 8/72 and first ship 4/73).

some lincpack numbers
http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033

some past threads mentioning 158, 4341, 3031 rain/rain4 comparison
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001e.html#9 MIP rating on old S/370s
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)

3031 was announced 10/77 and first shipped 3/78.

basically 3031 and 158 used the same processor engine. in the 158
... the engine was shared between running the 370 microcode and the
integrated channel microcode. for the 303x-line of computers, a
"channel director" was added ... bascially a dedicated 158 processor
engine with just the integrated channel microcode.

a single processor 3031 configuration was then really two 158
processor engines sharing the same memory ... one processor engine
dedicated to running the 370 microcode and one processor engine
dedicated to running the integrated channel microcode.

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

Code density and performance?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Code density and performance?
Newsgroups: comp.arch
Date: Mon, 18 Jul 2005 07:46:12 -0600

Nick Maclaren wrote:

Exactly where the optimum point lay (or lies) between extreme RISC
and (say) the VAX has varied in time, but has never been clear.
However, I have never known a time when the VAX level of complexity
was close to optimal (rather than too complex).  The 68000 or even
the 68020, yes, but no further.

FS in the early 70s went over to be super complex (but it was canceled
w/o every being announced ... although possibly billions were spent on
it before it was canceled)
http://www.garlic.com/~lynn/submain.html#futuresys

I've periodically commented that 801/RISC was large part re-action to
future system failure ... swinging in the exact opposite direction.
There were periodic comments in the mid-70s about 801/RISC consistently
trading off software (& compiler) complexity for hardware simplicity.
http://www.garlic.com/~lynn/subtopic.html#801

how do i encrypt outgoing email

From: lynn@garlic.com
Newsgroups: microsoft.public.outlook.installation
Subject: Re: how do i encrypt outgoing email
Date: Mon, 18 Jul 2005 10:26:16 -0700

Perry wrote:

I am looking for a way to encrypt out going email messages in
Outlook. We are not using exchange server

the standard technology is asymmetrical key cryptography ... what one
key encodes, the other key decodes (as opposed to symmetrical key
cryptography where the same key both encrypts and decrypts)

there is a business process, public key ... where one of the keypair
is designated "public" and freely distributed; the other of the
keypair is designated private, kept confidential and is *never*
divulged.

the standard method of sending encrypted email is to obtain the
recipient's public key .... this can be done in a number of ways and
most infrastructures provide ways of either dynamically obtaining the
recipient's key ... and having it already stored in your local trusted
public key repository.

the simple mechanism is to encode the data with the recipient's public
key and then only the recipient's private key is able to decode it.

because of asymmetrical cryptography performance issues ... many
implementations will generate a random symmetric key, encrypt the data
with the symmetric key and then encode the symmetric key ... and
transmit both the encrypted data and the encoded key. only the
recipient's private key can decode and recover the symmetric key ...
and only by recovering the symmetric key can the body of the message
be decrypted.

for somebody to send you encrypted mail ... you will need to have
generated a public/private key pair and transmitted your public key to
the other party. for you to send another party encrypted mail ... they
will have needed to have generated a public/private key pair ... and
you will need to have obtained their public key.

PGP/GPG have individuals exchanging keys directly and storing them in
their local trusted public key storage. PGP/GPG infrastructure also
support real-time, online public key registry.

there is a business process, digital signatures. here the hash of the
message is computed and encoded with the private key ... the messaage
and the digital signature is transmitted. the recipient recomputes the
hash of the message, decodes the digital signature (resulting in the
original hash) and compares the two hash values. if they are the same,
then the recipient can assume:

1) the message hasn't been altered since signing
2) something you have authentication ... aka the signer has access to
and use of the corresponding private key

There is also a PKI, certificate-based infrastructure that is targeted
at the offline email environment from the early 80s. Somebody dials
their local (electronic) post office, exchanges email, hangs up and is
now possibly faced with first time communication. This is somewhat the
letters of credit environment from the old offline sailing ship days
where the recipient had no provisions for authenticating first time
communication with complete strangers

An infrastructure is defined where people load up their trusted public
key repositories with public keys belonging to *certification
authorities*. When somebody has generated a public/private key pair
...  they go to a certification authority and register the public key
and other information. The certification authority generates a digital
certificate contain the applicants public key and other information
which is digitally signed by the certification authorities private key
(public can verify the digital signature using the certification
authorities public key from their trusted public key repository). This
provides a recipient a way of determining some information about a
stranger in first time communication ... aka the stranger has digital
signed a message and transmitted the combination of the message, their
digital signature and their digital certificate. The recipient 1)
verifies the certification authorities digital signature on the
digital certificate, 2) takes the public key from the digital
certificate and verifies the digital signature on the message, 3) uses
the other information in the digital certificate in determining basic
information about the total stranger first time communication).

You can push a message and your digital signature to a stranger
(possibly along with your digital certificate) ... but you can't
actually encrypt the message for the stranger ... w/o first obtaining
their public key.

IBM's mini computers--lack thereof

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM's mini computers--lack thereof
Newsgroups: alt.folklore.computers
Date: Tue, 19 Jul 2005 09:17:22 -0600

Charles Richmond writes:

Yeah, when you have an 8 megabyte buffer inside on the drive
electronics, it *can* speed things along a bit. And most mainframes
in the late 1970's did *not* even have 8 meg of main memory. Of
course, if the 8 meg buffer had to made of *cores*, then the drive
would need to be a little bit bigger.  ;-)

in the early 80s, you got 8mbyte buffers in 3880 controller,
3880-11/ironwood was 4k record cache and 3880-13/sheriff was full
track cache. a ironwood/sheriff controller might front 4-8 3380 drives
... at 630mbytes/drive ... that works out to 8mbyte cache for
2-5gbytes of data.

sheriff has some early marketing material that claimed 90 percent hit
rate reading records. the case was seequentially reading a file that
was formated ten 4k records to 3380 track; a read to first record on
the track was a miss ... but it brought the full track into the cache
...  so the next nine reads were "hits". you could achieve similar
efficiency by changing the DD statement to do full-track buffering
... in which case the controller cache dropped to zero percent hit
rate (the full track read would miss ... and then it would all be in
the processor memory).

ironwood was oriented towards paging cache ... but the typical
processor was 16mbyte to 32mbytes of real storage. a 4k page read
brought it first into the ironwood cache and then into the processor
memory. since a paging environment is effectively a form of caching
and both the ironwood and the processor was using LRU to manage
replacement ... they tended to follow similar replacement patterns.
since real storage tended to be larger effective cache than the
controller ... pages tended to age out of the controller cache before
they aged out of processor's memory.

in the mid-70s ... i had done a dup/no-dup algorithm for fixed-head
paging device (which tended to also have relative small limited size).
in the "dup" case ... when there was relatively low pressure on
fixed-head paging device ... a page that was brought into processor
memory also remained allocated on the paging device (aka "duplicate",
if the page was later replaced in real memory and hadn't been
modified, then a page-write operation could be avoided since the copy
on the paging device was still good). As contention for fixed-head
paging device went up, the algorithm would change to "no-dup" ... i.e.
when page was brought into real storage ... it was de-allocated from
the fixed-head device (aka "no-duplicate" ... this increased the
effective space on high-speed fixed-head paging devices ... but
required that every page replacement require a page-write (whether the
page had been modified or not).

So adapting this to ironwood ... all page reads were "distructive"
(special bit in the i/o command). "distrructive" reads that were in
the controller cache ... would de-allocate from the controller cache
after the read ... and wouldn't allocate in the cache on a read from
disk. The only way that pages get into the cache is when they are
being written from processor storaage (presumably as part of a page
replacement strategy ... aka they no longer exist in processor
storage). A "dup" strategy in a configuration with 32mbytes of
processor storage and four ironwoods (32mbytes of controller cache)
... would result in total electronic caching of 32mbytes in processor
storage (since most of the pages in ironwood would effectively be
duplicated in real storage). A "no-dup" strategy with the same
configuration could result in total electronic caching of 64mbytes
(32mbytes in processor storage and 32mbytes in ironwood).
past postings attached below

about the time of ironwood/sheriff ... we also did a project at sjr to
instrument operating systems for tracing disk activity. this was
targeted at being super-optimized so that it could continuously run as
part of standard production operation. tracing was installed on a number
of internal corporate machines in the bay area ... spanning a range of
commercial dataprocessing to engineering and scientific.

a simulator was built for the trace information. the simulator found
that (except for a couple edge cases), the most effective place for
electronic cache was at the system level; aka given fixed amount of
electronic cache ... it was most effective as a global system cache
rather than partitioned into pieces at the channel, controller, or disk
drive level.
this corresponds to my findings as an undergraduate in the
60s that global LRU out performed local LRU.

One of the edge cases involved using electronic memory on a drive for
doing some rotational latency compensation (not directly for caching per
se); basically data would start transfering to cache as soon as the head
was able ... regardless of the position on the track.

the other thing that we started to identity was macro data useage ... as
opposed to micro data pattern useage. A lot of data was used in somewhat
bursty patterns ... and during the burst there might be collection of
data from possibly multiple files being used. At the macro level ... you
could do things for improvements by load-balancing (the different data
aggregates that tended to be used in a common burst) across multiple
drives. The analogy for single drive operation is attempting to cluster
data that tended to be used together.

some of the disk activity clustering work was similar to some early
stuff at the science center in the early 70s ... taking detailed page
traces of application and feeding it into a program optimization
application (that was eventually released as a product called
"VS/Repack"). VS/Repack would attempt to re-organize a program for
minimum real-storage footprint (attempting to cluster instructions and
data used together in minimum number of virtual pages). see past
postings on vs/repack attached at bottom of this posting.

past postings on dup/no-dup, ironwood, sheriff:
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#54 mainframe question
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002d.html#55 Storage Virtualization
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2002o.html#52 ``Detrimental'' Disk Allocation
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003i.html#72 A few Z990 Gee-Wiz stats
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns

past postings on global/local LRU replacement:
http://www.garlic.com/~lynn/93.html#0 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#01 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#1 Multitasking question
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/94.html#4 Schedulers
http://www.garlic.com/~lynn/94.html#14 lru, clock, random & dynamic adaptive ... addenda
http://www.garlic.com/~lynn/94.html#49 Rethinking Virtual Memory
http://www.garlic.com/~lynn/96.html#0a Cache
http://www.garlic.com/~lynn/96.html#0b Hypothetical performance question
http://www.garlic.com/~lynn/96.html#10 Caches, (Random and LRU strategies)
http://www.garlic.com/~lynn/98.html#54 qn on virtual page replacement
http://www.garlic.com/~lynn/99.html#18 Old Computers
http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler)
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000f.html#34 Optimal replacement Algorithm
http://www.garlic.com/~lynn/2000f.html#36 Optimal replacement Algorithm
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
http://www.garlic.com/~lynn/2003f.html#55 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#55 Advantages of multiple cores on single chip
http://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2004b.html#47 new to mainframe asm
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004.html#25 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004i.html#0 Hard disk architecture: are outer cylinders still faster than
http://www.gar