List of Archived Posts

2000 Newsgroup Postings (01/04 - 03/05)

2000 = millennium?

Computer of the century

Computer of the century

Computer of the century

Computer of the century

IBM XT/370 and AT/370

Computer of the century

"OEM"?

Computer of the century

Computer of the century

Taligent

I'm overwhelmed

I'm overwhelmed

Computer of the century

Computer of the century

Computer of the century

Computer of the century

I'm overwhelmed

Computer of the century

Computer of the century

Computer of the century

Computer of the century

Computer of the century

System Activity vs IND LOAD

Why is EDI dead? Is S/MIME 'safe'? Who and why?

Computer of the century

Why is EDI dead? Is S/MIME 'safe'? Who and why?

Homework: Negative side of MVS?

Operating systems, guest and actual

Computer of the century

Computer of the century

Homework: Negative side of MVS?

SmartCard with ECC crypto

IBM 360 Manuals on line ?

SmartCard with ECC crypto

"Trusted" CA - Oxymoron?

"Trusted" CA - Oxymoron?

Vanishing Posts...

"Trusted" CA - Oxymoron?

"Trusted" CA - Oxymoron?

"Trusted" CA - Oxymoron?

"Trusted" CA - Oxymoron?

Historically important UNIX or computer things.....

Historically important UNIX or computer things.....

TLS: What is the purpose of the client certificate request?

question about PKI...

TLS: What is the purpose of the client certificate request?

TLS: What is the purpose of the client certificate request?

IBM RT PC (was Re: What does AT stand for ?)

APPC vs TCP/IP

APPC vs TCP/IP

Correct usage of "Image" ???

APPC vs TCP/IP

Hotmail question

OS/360 JCL: The DD statement and DCBs

OS/360 JCL: The DD statement and DCBs

RealNames hacked. Firewall issues.

Multithreading underlies new development paradigm

Multithreading underlies new development paradigm

RealNames hacked. Firewall issues.

64 bit X86 ugliness (Re: Williamette trace cache (Re: First view of Willamette))

64 bit X86 ugliness (Re: Williamette trace cache (Re: First view of Willamette))

Mainframe operating systems

distributed locking patents

Cybersafe & Certicom Team in Join Venture (x9.59/aads press release at smartcard forum)

CRC-16 Reverse Algorithm ?

Difference between NCP and TCP/IP protocols

Mainframe operating systems

APL on PalmOS ???

APL on PalmOS ???

Mainframe operating systems

Difference between NCP and TCP/IP protocols

Difference between NCP and TCP/IP protocols

Difference between NCP and TCP/IP protocols

Mainframe operating systems

Mainframe operating systems

Mainframe operating systems

Mainframe operating systems

Mainframe operating systems

Atomic operations ?

Ux's good points.

Ux's good points.

Ux's good points.

Ux's good points.

Difference between NCP and TCP/IP protocols

Ux's good points.

Ux's good points.

ASP (was: mainframe operating systems)

Ux's good points.

Ux's good points.

Ux's good points.

Ux's good points.

Predictions and reality: the I/O Bottleneck

Those who do not learn from history...

Those who do not learn from history...

2000 = millennium?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 2000 = millennium?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 04 Jan 2000 02:11:59 GMT

posted to a similar discussion in seattle.general newsgroup:

isn't there something about zero wasn't introduced until sometime
around the 10th century ... possibly someplace in africa? prior to
that things like roman was I, II, III, IV, V, VI, VII, VIII, IX, X
i.e. it wasn't decimal as we know it today since there was no zero
(various of the existing conventions & concepts that predate the
introduction of zero could appear to be out of sync with our current
concept of arithmatic).

slightly related posting I found in an archive & posted early last
year:

Subject: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
Newsgroups: sci.skeptic,alt.folklore.urban,alt.folklore.computers
Date: 12 Feb 1999 14:20:17 -0800

date problems somebody posted to a newsgroup in 1984:

1.In 1969, Continental Airlines was the first (insisted on being the
first) customer to install PARS.  Rushed things a bit, or so I hear.  On
February 29, 1972, ALL of the PARS systems cancelled certain
reservations automatically, but unintentionally.  There were (and still
are) creatures called "coverage programmers" who deal with such
situations.

2.A bit of "cute" code I saw once operated on a year by loading a
byte of packed data into a register (using INSERT CHAR), then used LA
R,1(R) to bump the year.  Got into a bit of trouble when the year 196A
followed 1969.  I guess the problem is not everyone is aware of the odd
math in calendars.  People even set up new religions when they discover
new calendars (sometimes).

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch
Date: Tue, 04 Jan 2000 22:02:03 GMT

handleym@ricochet.net (Maynard Handley) writes:

- the OS/360 debacle and the way IBM was very late to the party in
supplying interactive (non-batch) computing

TSS & TSO were the officially sanctioned interactive, non-batch
computing ... but IBM did have CP/67 and VM/370 offerings ... which,
while CP67/VMS370 had a compareatively small install base (compared to
OS/360), actually had a larger customer install base than most
corporations total install customer base ... in fact, the internal
corporate CP67/VM370 install base (smaller than the customer install
base) was larger than many coprations total customer install base).

There was also APL/360 interactive and later things like VS/PC.

At one time, I was creating highly modified VM/370 production systems
and shipping them to some internal sites where it was run on a small
number of the internal computers ... although I believe that number
was still larger than the total life-time install base for Multics.

various IBM & interactive references:

http://www.garlic.com/~lynn/99.html#126
http://www.garlic.com/~lynn/99.html#127
http://www.garlic.com/~lynn/99.html#142
http://www.garlic.com/~lynn/99.html#177
http://www.garlic.com/~lynn/99.html#237

&

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

misc. other references:

http://www.garlic.com/~lynn/95.html#14
http://www.garlic.com/~lynn/96.html#24
http://www.garlic.com/~lynn/96.html#35
http://www.garlic.com/~lynn/97.html#15
http://www.garlic.com/~lynn/99.html#7
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#76
http://www.garlic.com/~lynn/99.html#100
http://www.garlic.com/~lynn/99.html#109
http://www.garlic.com/~lynn/99.html#112

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.unisys
Date: Tue, 04 Jan 2000 22:21:17 GMT

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

In article <slrn8722v4.4s.paul@shippo.virgin.net>,
The S/390 TOD is defined to keep track of atomic time, with an epoch of
1900-01-01 00:00:00 GMT (synchronised to UTC in 1972, not 1958 as for TAI),

I remember working on the redbook TOD definition for what was coming
out as s/370. Spent about 3 months elapsed time on it with a couple
other people ... that was where I got indoctrinated that the first of
the century (as per the architcture definition) was 1901-01-01
00:00:00 GMT ... and to the issue of leap-seconds ... which could be
positive or negative & zero, one or more.

Initially, Most 370 operating systems (incorrectly) initialized the
TOD clock to 1970-01-01 00:00:00 GMT (not 1901) ... and then some
"fixed" it by (incorrectly) initializing to 1990-01-01 00:00:00.

The s/370 tod clock is 64bits with the 12bit being defined as being
microsecond resolution (although the architecture didn't require
clocks to do microsecond or even submicroseconds tics). That makes the
32bit (first bit of the high word) equal to 1024/1000 of a second
(i.e. slightly longer than a second) ... multiple by 1000 and shift
right 10 bits to convert the high word to actual seconds.

it was in a timer register; better than 360 where the clock was
located in memory and had to steal memory cycles for the timer tic.

misc. references:

http://www.garlic.com/~lynn/93.html#16
http://www.garlic.com/~lynn/96.html#30
http://www.garlic.com/~lynn/96.html#37
http://www.garlic.com/~lynn/97.html#7
http://www.garlic.com/~lynn/99.html#102

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch
Date: Tue, 04 Jan 2000 22:53:05 GMT

Tim Bradshaw writes:

either).  It was to do with IBM claiming that FS was life-or-death for
them when evidently it wasn't.  And there was some monopolistic
consequence of that, or so the book claims.

i think that the life-or-death statements were more akin to internal
politics trying to justify a project

it is on par with presentation that once was made claiming that if the
internal network wasn't converted to SNA that the internal network
would start failing.

misc. ref:

http://www.garlic.com/~lynn/96.html#24
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#100
http://www.garlic.com/~lynn/99.html#112

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.unisys
Date: Wed, 05 Jan 2000 19:16:03 GMT

I counted bits from the opposite end compared to the diagram in the
following reference. The low-order (smallest resolution) 12 bits (bits
0-11) are "sub-microsecond" with bit 12 (from the right) or bit 51
(from the left) being 1 microsecond.

And as noted in the programming notes ... TOD epoch zero is january 1,
1990 ... not January 1, 1991 (first day of the century) as per my
prior note.

4.6.1.1 Format

The TOD clock is a binary counter with the format shown in the
following illustration. The bit positions of the clock are numbered 0
to 63, corresponding to the bit positions of a 64-bit unsigned binary
integer.

                  1 microsecond___
                                  v
    ______________________________________
   |                             | |      |
   |_____________________________|_|______|
   0                             51      63

   In  the  basic  form,  the TOD clock is incremented by adding a one in bit
   position 51 every microsecond.    In  models  having  a  higher  or  lower
   resolution,  a  different  bit position is incremented at such a frequency
   that the rate of advancing the clock is the same as if a one were added in
   bit position 51 every microsecond.   The resolution of the  TOD  clock  is
   such that the incrementing rate is comparable to the instruction-execution
   rate of the model.

Programming Notes:

     1. Bit position 31 of the clock is incremented every 1.048576
seconds; for some applications, reference to the leftmost 32 bits of
the clock may provide sufficient resolution.

     2. Communication between systems is facilitated by establishing a
standard time origin, or standard epoch, which is the calendar date
and time to which a clock value of zero corresponds.  January 1, 1900,
0 a.m. Coordinated Universal Time (UTC) is recommended as the standard
epoch for the clock. This is also the epoch used when the TOD clock is
synchronized to the external time reference (ETR). Note that the
former term, Greenwich Mean Time (GMT), is now obsolete and has been
replaced with the more precise UTC.

     3. A program using the clock value as a time-of-day and calendar
indication must be consistent with the programming support under which
the program is to be executed. If the programming support uses the
standard epoch, bit 0 of the clock remains one through the years
1972-2041. (Bit 0 turned on at 11:56:53.685248 (UTC) May 11, 1971.)
Ordinarily, testing bit 0 for a one is sufficient to determine if the
clock value is in the standard epoch.

     4. In converting to or from the current date or time, the
programming support must take into account that "leap seconds" have
been inserted or deleted because of time-correction standards.

     5. Because of the limited accuracy of manually setting the clock
value, the rightmost bit positions of the clock, expressing fractions
of a second, are normally not valid as indications of the time of
day. However, they permit elapsed-time measurements of high
resolution.

     6. The following chart shows the time interval between instants
at which various bit positions of the TOD clock are stepped. This time
value may also be considered as the weighted time value that the bit,
when one, represents.

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

for a more detailed description of 370 tod clock see:

http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/4%2e6%2e1

4.6.1 Time-of-Day Clock

The time-of-day (TOD) clock provides a high-resolution measure of real
time suitable for the indication of date and time of day. The cycle of
the clock is approximately 143 years.

In an installation with more than one CPU, each CPU may have a
separate TOD clock, or more than one CPU may share a clock, depending
on the model. In all cases, each CPU has access to a single clock.

Subtopics:

     4.6.1.1 Format
     4.6.1.2 States
     4.6.1.3 Changes in Clock State
     4.6.1.4 Setting and Inspecting the Clock

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

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

IBM XT/370 and AT/370 (was Re: Computer of the century)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM XT/370 and AT/370 (was Re: Computer of the century)
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 06 Jan 2000 02:13:31 GMT

The XT/AT/370 didn't support all of the 370 instruction set ... there
were omissions in the supervisor instructions. It ran a modified
version of VM/370 that took into account the supervisor differences,
for instance I/O was done by communicating with a monitor program
running on the 8088/80286 ... which then did actual disk accesses,
keyboard operation, display, etc.

It also had a modified version of one of my page replacement
algorithms and my CMS page-mapped file support (which was never
shipped, other than internally ... or possibly AT&T longlines, in the
standard product to customers) ... biggest problem was that it
operated in severe memory constrained environment (by most 370
operating system & application standards).

Initial version ... before first customer ship ... was going to go out
with only 384kbytes of "370" memory ... which held the resident kernel
as well as all paged application code & file. I did some early
benchmarks which showed severe page thrashing ... and notice the page
file was mapped into a XT 100mills/access hard disk (on a good day,
disk was saturated at 10 accesses/second). By the time the first box
shipped to customers they got it up to 512kbytes of "370" memory which
slighted mitigated some of the problem.

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.unisys
Date: Fri, 07 Jan 2000 08:00:43 GMT

I have a slightly different view of the IBM/PC.

The combination of th IBM name with a 3270 emulator plus spreadsheet
resulted in a corporation being able to upgrade their 3270 terminals
for only slightly more than the cost of a straight 3270 ... and a
person could get on their desk, in one display/keyboard ... both their
traditional business computer terminal as well as a machine that could
do local business processing (like pc spreadsheet).

It made the ibm/pc market million+ customer base (just the internal
IBM market segment was several hundred thousand). I don't remember any
specific numbers, but I don't believe there was any other vendor with
a million+ PC install base prior to the IBM/PC.

Some misc. history, in the late '70s we were trying to get 3270s on
every desk in the company and were being met with various kinds of
resistance, including 3270 terminal orders required VP-level sign-off
(and had to be included in the fall budget planning cycle). We
presented the business case that the monthly cost of a 3270 (using
3-year amortized capital expenditure) was about the same as a business
phone ... and business phones were a standard feature on everybody's
desk, not requiring VP-level authorization for each individual phone.
That broke things loose and started to see every desk having a 3270
terminal ... as well as significant home terminal program.

In any case, with any market the size of the ibm/pc, there is bound to
be clones ... just like there was already a thriving 3270 terminal
clone business prior to the PC.

Whatever problems and shortcomings that came later, I would contend
were, in part, because many of the people had too much history of
succesful mainframe business practices ... which didn't translate well
into the PC market place once it started maturing (lots of companies
have had problems dealing with too much success).

In contrast, I remember having dinner a couple times with the MAC
developers early in the MAC development cycle. Somewhat simplifying
... their position was that a MAC would never, ever be found any place
but on a kitchen table; I contended that MAC would never (ever) be a
profitable business unless some business/commerce application was
supported ... that at least they could do was provide mainframe 3270
terminal emulation attachment so they could sell into the corporate
market. They contended that would never, ever happen, no MACs in
offices and/or supporting business applications. Desktop publishing
was somewhat of a compromise ... it theoritically could be done on
kitchen table as a cottage industry ... even tho most of the desktop
publishing MACs appeared to be in commercial establishments for
commercial purposes.

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

"OEM"?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "OEM"?
Newsgroups: alt.folklore.computers
Date: Fri, 07 Jan 2000 08:13:37 GMT

OEM in the '70s was for "other equipment manufactur" ... also plug
compatible manufactur (PCM) ... which built equipment that were plug
compatible with IBM devices that attached to IBM mainframes
(frequently referred to as clones these days).

the only thing that I remember that might have been in the 60s for IBM
mainframe was Ampex memory. Supposedly a project that I worked on
as an undergraduate in the late '60s is credited with origindating
the (ibm) PCM/OEM business.

misc. reference:

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

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers
Date: Fri, 07 Jan 2000 08:39:13 GMT

Eric Chomko writes:

Is this the same VM of JCL fame?

JCL ... job control language ... basically for batch operation when
the programmer isn't around.

VM had extensive development for interactive ... although the basic
monitor provided virtual machine function ... which could also be used
to operate other batch operating systems (of JCL fame, dos/360,
pcp/360, mft/360, mvt/360, vs1, vs2, mvs, os/390, etc).

VM continues to exist ... and as well, IBM has migrated many of the VM
features into the microcode of the current generation of mainframes
... referred to as LPARS (logical partitions) ... and probably nearly
all installed machines are configured with logical partitions.

for recent posting on vm-related interactive:

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

misc. other references:

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

there might also be some interest some of the gml->SGML->HTML
evolution

http://www.garlic.com/~lynn/99.html#197
http://www.sgmlsource.com/history/roots.htm
http://web.archive.org/web/19981206171107/http://www.sgmlsource.com/history/roots.htm

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch
Date: Fri, 07 Jan 2000 15:50:00 GMT

Tim Shoppa writes:

I do realize that you believe that I'm completely wrong in that
IBM had 8" floppies before Shugart Associates ever existed.

8" floppies were common microload mechanism in IBM controllers

I had been told by some san jose folks that most of the non-ibm disk
efforts formed in the 70s ... were by gpd san jose people who left and
started independent efforts.

for instance:

http://www.alshugart.com/milestones.html

One of the other people that worked on the 2321 (data noodle?) went on
to do the memorex disk effort and then help form one of the early
relational database companies.

with regard to the following reference:

http://www.garlic.com/~lynn/96.html#18

in the late '70s, I was told that so many senior people had left, that
they were short on channel architecture expertise. In a couple cases
where the engineering labs were claiming that the operating system
software was wrong ... turned out to be they were doing something in
the disk controller that violated channel architecture ... and I would
have time being channel architecture arbitrator between them and
POK. Having the test cells running under operating system (rather than
stand-alone) tended to flush out hardware problems (especially
architecture violations) earllier. A specific one that I remember was
when they tried to do unsolicited unit check ... it took 3 months of
argueing to get that fixed.

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

Taligent

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Taligent
Newsgroups: alt.folklore.computers
Date: Sat, 08 Jan 2000 18:13:48 GMT

taligent was mainly targeted at the client portion of a client/server
paradigm ... with most of the support for drawing menu/screens for the
client. In a intensive JAD with their people in looked like a 30%-50%
hit to taligent in terms of new features &/or rewritten code to
support industrial stength computing applications.

Even in its targeted domain ... a medium sized project resulted in
something like 3500 classes compared to 600-700 implemented in some
other products (i.e. it still needed some maturing). It seemed like a
number of the products from the period went for low learning curve for
turning out graphical demos but turned out to be much more people intensive
doing real live apps (compared to some other environments with higher learning
curve .. somewhat analogous to the recent C++/Ada implication in the perl
related posting in this same ng).

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

I'm overwhelmed

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I'm overwhelmed
Newsgroups: alt.folklore.computers
Date: Sun, 09 Jan 2000 05:00:14 GMT

"Jack Peacock" writes:

set, something simple in the 360/20 range.  I bet a 360 emulator running
on a K7 at 1Ghz would compare favorably to a 370/125 at least, maybe
even a 168.  And imagine how fast Autocoder would run on a 1401
emulator!

see

http://www.funsoft.com/

for os/390 running on intel processor.

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

I'm overwhelmed

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I'm overwhelmed
Newsgroups: alt.folklore.computers
Date: Sun, 09 Jan 2000 18:27:36 GMT

"Jack Peacock" writes:

set, something simple in the 360/20 range.  I bet a 360 emulator running
on a K7 at 1Ghz would compare favorably to a 370/125 at least, maybe
even a 168.  And imagine how fast Autocoder would run on a 1401
emulator!

oh yes ... the 370/125 was about 100kips 370 microcoded machine
... microcode that ran about 10:1 (i.e. 10 "native" machine
instructions per every 370 instruction, i.e. about 1 mip native
instruction machine, the other IOP in the 115/125 was only about
a 800kip native machine ... and so the 115 was only about 80 kip
370 machine)).

aslo, for ecps assist on the 138/148 machines ... we got about a 10:1
performance improvement dropping straight-line 370 kernel code into
native microcode.

assuming 370 simulation code that comes anywhere close to the
efficiency of the microcode of the low-end 370 processors (115, 125,
135, 145) ... then a 1Ghz K7 would provide significantly more 370 MIPs
than a 168.

misc. references:

http://www.garlic.com/~lynn/94.html#21
http://www.garlic.com/~lynn/94.html#27
http://www.garlic.com/~lynn/95.html#3

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.unisys
Date: Sun, 09 Jan 2000 18:43:08 GMT

amolitor-at writes:

	Just a for-instance that's recent. Sysplex. A *really* nice
chunk of software that IBM did, that's spawned a great deal of

my wife worked for the person that headed up inter-system coupling
part of FS. After that she worked on JES2/JES3 and then was con'ed
into going to POK to be responsible for loosely-coupled architecture
where she developed the peer-coupled shared data architecture
.. which was the basis for IMS hot standby and then parallel sysplex.

misc. reference:

http://www.garlic.com/~lynn/98.html#30
http://www.garlic.com/~lynn/98.html#37
http://www.garlic.com/~lynn/98.html#40
http://www.garlic.com/~lynn/99.html#71

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers
Date: Sun, 09 Jan 2000 22:20:25 GMT

glass2 writes:

name of Runtime Analyzer for MVS and OS/390.  Additionally, I
remember some work that the IBM scientific centers did for certain
national archives (Was it the Spanish National Archives) which
involved cataloging and computer imaging some of their documents.

i believe this was (at least) the madrid science center during much of
the '80s as part of getting ready for the 500th aniversery of
1492/columbus. There was a bunch of imaging and indexing of loads of
documents (and preperation of cdrom(s) of the material).

I had stopped by there in the mid-80s for a visit on the project.

misc. reference

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

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers
Date: Sun, 09 Jan 2000 22:44:48 GMT

In article <853ols$d6m@nnrp4.farm.idt.net>, Eric Chomko writes:

Funny how IBM has failed to inspire any
serious SW project of any success since the 360. And wasn't Java a Sun
thing in the early days? How could IBM have been in it and missed the
boat?

I thot java had roots back in dolphin ... the project to do new OO
operating system. I had been called in to look at doing industrial
strength areas of dolphin ... and then i didn't hear anything for a
while ... then the next thing I know, I'm in a meeting with the
General Manager of the java organization ... who I had known 20 years
previously as one of the two people responsible for pascal/370 &
vs/pascal.

random references:

http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/99.html#63
http://www.garlic.com/~lynn/99.html#222

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch
Date: Sun, 09 Jan 2000 23:02:28 GMT

bill@wjv.com.REMOVEME (Bill Vermillion) writes:

At least you'll find some interseting picture from electon
microscopes in Switzerland, to head design, chips, etc., at other
sites around the globe.  It's an interesting and amazing company.

i was told at one time the los gatos vlsi lab was the first place that
used a scanning electron microscope for diagnosing a running chip ...
may have been with the JIB' (jib prime) microprocessor ... used in
the original 3880 disk controllers. los gatos also did blue iliad
... the first 32bit 801 RISC processor.

random references:

http://www.garlic.com/~lynn/94.html#22
http://www.garlic.com/~lynn/94.html#47
http://www.garlic.com/~lynn/95.html#5
http://www.garlic.com/~lynn/95.html#6
http://www.garlic.com/~lynn/95.html#11
http://www.garlic.com/~lynn/98.html#25
http://www.garlic.com/~lynn/98.html#26
http://www.garlic.com/~lynn/98.html#27
http://www.garlic.com/~lynn/99.html#64

there have also been various statements about 801 heavily influencing
both AMD 29k and HP snake.

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

I'm overwhelmed

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: I'm overwhelmed
Newsgroups: alt.folklore.computers
Date: Sun, 09 Jan 2000 23:25:45 GMT

kragen@dnaco.net (Kragen Sitaker) writes:

Suppose you had a machine that handled
- 1000 interactive terminals at 9600 bps -- total 9.6 megabits
- 50 tape drives at 6250 bpi and 100 feet per second -- that's
100 * 6250 * 50 = 31 250 000 bits per second, total 31.25 megabits
- 20 high-speed printers at 17,600 bits per second -- 352 000 bits per
second, 0.352 megabits
- 20 disks at 500 kilobytes per second -- that's 10 megabytes per second,
or 80 megabits

i believe in the past MINIs have tried to move into this space ... and
some have used ethernet for terminal concentrator.

old time disk/tape would pose a little of a problem since not only was
it the bit rate ... but they had no intermediate buffering. memory was
scarce and they all used the mainframe memory so there was a lot of
direct memory access with associated latency and overrun issues.

The interesting thing about various of these configurations in the 60s
is they talked about E/B ratios where the numbers were in terms of
MIPs and bytes ... most E/B ratios these days are in terms of MIPs and
bits (i.e. bits transferred per instruction executed has dropped by at
least an order of magnitude).

again, emulation of 390 on intel hardware:
http://www.funsoft.com/

random reference:

http://www.garlic.com/~lynn/93.html#31

a problem that you get when there is that much depending on a single
box, failure modes become an issue. Lots of PCs today are configured
with fake parity memory. I think the best PC memory is possibly 8+2
ECC.  (correct 1 bit error and detect two bit). Mainframe memory may
be 64+16 (correct 15bit errors, detect 16 bit errors) or better.

misc. other references:

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

some discussion of support for tens of thousands of interactive
terminals

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

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers
Date: Tue, 11 Jan 2000 01:51:43 GMT

Eric Chomko writes:

Hey, listen I don't hate IBM. In fact, Ted Codd, happens to be sort of a
hero of mine. The guy really pioneered databases while working at IBM.
Still does, if I'm not mistaken.

Eric

for discussion on System_R (and various early relational).

http://www.mcjones.org/System_R/

I played a small part working with Woody Garnett developing DWSS
... which allowed multiple instances/threads of System_R to share
common virtual storage (we worked with Vera Watson and Jim Gray). We
also helped with some of the technology transfer from San Jose to
Endicott for SQL/DS.

In the above & the following references, Baker made some reference
about doing technology transfer from Endicott back to STL for DB2
(before going to Oracle).

random references:

http://www.garlic.com/~lynn/aadsmore.htm#dctriv
http://www.garlic.com/~lynn/95.html#13

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers
Date: Wed, 12 Jan 2000 03:37:41 GMT

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

> The accounting machine I remember was the 407.

This was IBM's flagship of its EAM systems.  People today would be
amazed at the programming sophistication that machine could do.  I
wish some of today's programmers knew how to write software that
could do everything that machine did.

i spent some amount of time using 407 & playing with the plugboard

url I found courtesy of alta-vista

http://vmdev.gpl.ibm.com/devpages/eheman/dad407.html

in the following photo, card reader on the left, printer in the middle
top ... and the right side was where the plug board slid down (pull
out handle ... I remember the "door" was hinged at the bottom so it
was little like opening oven door).

http://vmdev.gpl.ibm.com/devpages/eheman/407reg2.html

& above author's home page

http://vmdev.gpl.ibm.com/devpages/eheman/

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers
Date: Wed, 12 Jan 2000 04:06:02 GMT

misc. other URLs from alta-vista that happen to mention 407

http://www-5.ibm.com/uk/about/history2.html
http://www.isu.edu/comcom/news_letter/early.html
http://web.archive.org/web/20000823135031/http://www.isu.edu/comcom/news_letter/early.html
http://www.mta.ca/~amiller/cs3711/ibm650/ibm650.htm
http://www.world.std.com/~reinhold/early.computers.html
http://www.users.nwark.com/~rcmahq/jclark/adoc.htm

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.unisys
Date: Wed, 12 Jan 2000 22:07:24 GMT

Brian Inglis writes:

Their goal is for the customer to experience zero failures before
a part is upgraded or changed by the customer. They build
redundant parts with automatic failover inside the boxes they
sell. At PM time the local FE CSR checks if any parts have died
and orders replacements for installation at the next PM. I no
longer work with IBM gear but the total approach is a revelation
to those exposed only to mini or micro systems where some piece
of hardware is always dying and causing outages.

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
--
Brian_Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
				use address above to reply

how 'bout an objective of having no more than five channel checks
(something like SCSI bus error) in a 12month period across all
machines in all customer shops (this is not avg of five errors per
machine in a year ... this is five errors total across all machines in
a year).

random reference:

http://www.garlic.com/~lynn/94.html#24
http://www.garlic.com/~lynn/96.html#27

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch,comp.sys.unisys
Date: Wed, 12 Jan 2000 22:26:11 GMT

an even more interesting concept in the previous reference about five
channel checks (which are recoverable/retryable data errors) is the
reporting & data gathering infrastructure such that it can even be
accurately reported (and raise an alarm if there are 15 errors instead
of <5 errors across all machines in a period of a year).

oh yes ... 100% availability for six years (automated operator & ims
hot standby) ... ref:

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

other references regarding availability thread

http://www.garlic.com/~lynn/99.html#182
http://www.garlic.com/~lynn/99.html#184
http://www.garlic.com/~lynn/99.html#185
http://www.garlic.com/~lynn/99.html#186

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

System Activity vs IND LOAD

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System Activity vs IND LOAD
Newsgroups: bit.listserv.vmesa-l
Date:    Wed, 12 Jan 2000 09:45:15 -0800

oops, resend from correct userid

the way that I wrote the original smoothed value stuff including for
IND LOAD and other smooted values was it calculated the increment
activity for the most recent interval. If the most recent interval was
one minute then the smoothed values were decreased by 7/8ths and the
activity for the most recent interval added in. If the most recent
interval as 1 second, the smoothed values were decreased by 479/480
and the activity for the most recent interval added in (the smooted
interval was taken as 8 minute base.

Given 1 minute update interval ... transition from 100% cpu to zero
cpu would have a long tail ... since the smoothed cpu value would be
decremented by 7/8ths every minute (with nothing added back in).  If
transition from 100% cpu to 0% cpu happened exactly on a interval
boundary .. then eight 1 minute intervals of 0% cpu would reduce the
100% by 7/8ths during each interval and add zero back in. After eight
intervals, 7/8**8 isn't converging to zero real fast (still ..34)).

There were later changes that looked at doing some of the smoothed
feedback numbers to more quickly adapt to large changes with things
like current smoothed value decreased by 3/4 and twice the the most
recent activity added in (in the previous example 3/4**8 converges
faster to zero i.e. .1 instead of .34).

Disclaimer: I actually haven't seen the code in quite some time.

Anne & Lynn Wheeler      lynn@adcomsys.net, lynn@garlic.com
  http://www.garlic.com/~lynn/  http://www.adcomsys.net/lynn/

Why is EDI dead? Is S/MIME 'safe'? Who and why?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is EDI dead?  Is S/MIME 'safe'?  Who and why?
Newsgroups: comp.security.misc,sci.crypt,alt.security.pgp
Date: Thu, 13 Jan 2000 20:07:54 GMT

EDI has been both translators and the private value added networks that
provide secure, reliable connectivity between the trading partners
(s/mime addresses some of the secure issues ... but existing internet
mail transport isn't exactly known for 100% reliability).

translators are complex because they operate between commercial legacy
systems and normalized transport format that has tended to be industry
specific.

it has been in extensive use for lots of b-to-b ... which you
wouldn't normally hear about in non-b-to-b locals (say internet
currently is small percentage of retail commerce and retail commerce
is small percentage of b-to-b, aggregate of value related to
EDI-transactions can easily be several orders of magnitude larger than
existing internet retail commerce).

another body playing here is OMG

http://www.omg.org/

in part because it isn't just the syntax of the information exchange
but also the business operations that operate on the information
exchanged (i.e. not only need to normalize information format ... but
also semantics of the business operations).

XML/internet, etc related EDI reasonably can move it into higher
volume & lower valued transactions (lot of existing, more expensive
EDI is wrapped around high value activities).

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch
Date: Thu, 13 Jan 2000 21:38:50 GMT

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

Somebody from Microsoft wrote a book on how to avoid coding errors.
It was written, however, with a C-bias.  Ada programmers who read
that book judged it a waste of time because about 90% of the common
coding bugs discussed were impossible in Ada.

slightly related ref ... not so much language syntax but surely
language useage

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

 aargh ... i've asserted for quite some time that over half (maybe 90%)
 of the internet, c-based operating system, & c-based application
 exploits are systemic of C's implicit string length architecture
 (i.e. being able to exploit buffer overruns because the programmer has
 relied on implicit string lengths ... something that is relatively
 less frequent on systems that rely on explicit string/buffer length
 paradigms).

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

Why is EDI dead? Is S/MIME 'safe'? Who and why?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is EDI dead?  Is S/MIME 'safe'?  Who and why?
Newsgroups: comp.security.misc,sci.crypt,alt.security.pgp
Date: Thu, 13 Jan 2000 22:18:16 GMT

On Fri, 14 Jan 2000 00:43:36 +0800, sb5309 wrote:

What is "remote document processing business - invoices, price-lists,
technical drawings etc." ?

I am curious. Thanks

there are printer outsourcers with locations around the country ...
that are used by lots of industries ... including computer software
vendors; somebody can call their vendor of choice and order a manual;
the request is routed to the printing plant closest to the requester
... and the manual is printed "just in time" and shipped directly to
the requester.

these print oursourcers also handle big batch jobs like monthly bills
& statements. Large percentage of bills, statements, etc are
outsources to these 3rd party printers (i.e. in some locals, nearly
all utility bills/statements are outsourced; i.e. water, sewage,
garbage, power, etc).

Batch bill/statement input tends to be tape ... frequently in some
sort of 1403 or AFP format ... which is then processed for printing
(the print house may even have to have specialized per-client data
extraction to get name/address out of the bill/statement data for
envelope printing).

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

Homework: Negative side of MVS?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Homework: Negative side of MVS?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 14 Jan 2000 19:28:07 GMT

I am writing a paper for a class on MVS.  I am suppose to do a
"pro and con" type paper.  I can find info on the positive side
of MVS, yet I am having a hard time finding info on the negative
side of the OS.  Any help would be appreciated.

I've talked to a number of large organizations that retired MVS and
coverted to something else not as good. Reason given was that their
MVS staff was retiring and they weren't able to backfill the slots.

In many cases, they found they weren't able to compete with financial
organizations for scarce resource. Even in some financial
organizations, they identify in the top five business risks critical
MVS staff with over 30 years (nearing retirement age, kids are all
thru school, house paid for, and it is getting difficult to motivate,
even with significant salary raises).

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

Operating systems, guest and actual

From:    Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Operating systems, guest and actual
Newsgroups: bit.listserv.vmesa-l
Date:    Thu, 13 Jan 2000 22:15:28 -0800

XT/370 ran a custom version of CP ... it was a custom modified 68k that
provided 370 except for things like I/O. which CP communicated with a
monitor running on DOS.

misc. ref:

http://www.garlic.com/~lynn/94.html#42
http://www.garlic.com/~lynn/2000.html#5

the XT/370 (& AT/370) was card that fit inside PC case.

there was faster one that was a separate box and had cable that hooked
into the PC.

the following possibly is one of those machines in pok .... even tho
it was listed as 4341.:

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

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch
Date: Sat, 15 Jan 2000 18:14:24 GMT

some mainframe paradigms have both data structures (strings) and
buffer/io operations with explicit lengths & have had fewer instances
of buffer overflow ... in part because explicit length paradigm keeps
programmers somewhat more cognizant of the issues (they have to do
more work ... but then again they have to do more work).

although when i was undergraduate and did teletype support, i used one
byte arithmatic ... which worked until somebody defined a psuedo
teletype device which violated assumed implicit/max. teletype transfer
lengths

misc. buffer overflow ref:

http://www.lilli.com/360-67 (corrected) http://www.multicians.org/thvv/360-67.html
http://www.garlic.com/~lynn/99.html#44

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

Computer of the century

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer of the century
Newsgroups: alt.folklore.computers,comp.arch
Date: Thu, 20 Jan 2000 02:39:07 GMT

random activities that predate the parallel sysplex were numerious ibm
shared disk cluster environments from the late '60s and early 70s
... like PARS/ACP cluster (airline control program that became TPF),
numerous shared disk configurations from the early to mid 70s with
two-way, four-way, and eight-way disk sharing configuration ... then
enhanced to 16-way. Besides reserve/release (device level locking)
from the mid-60s, PARS added fine-grain locking to 3830 disk
controller in the early 70s.

random references:

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

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

Homework: Negative side of MVS?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Homework: Negative side of MVS?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 20 Jan 2000 02:45:20 GMT

actually we were working on project with one of the labs ... and in a joint
meeting with the management and staff ... one of the staff brought up why
are we doing all this conversion off of mvs to another platform ... and the
management said that they had numerous reqs. out for mvs support people for
the past year and not one had been answered (and subsequent look at it
showed the existing gov. scale was in fact less than the going scale in the
financial industry, in some extreme cases gov. scale is 1/3rd general
industry). that the existing people were all there was and they were unable
to get any more ... and they had been loosing people in the group. The MVS
people were really unhappy.

We have good friends at another lab ... including the support staff (which
was outsourced contract ... the contract typically ran for five years ...
whenever a different company won the contract ... the existing people were
moved from the old company to the new company). The shutoff of the last MVS
system was scheduled to be the same day the last senior MVS support person
retired

In both cases, the locations went to something that provided much less
service to their location ... and numerous people were unhappy.  There have
been a half dozen other cases where we have had less in depth contact ...
but the comments were similar.

A possible pending one is large national database that was developed by two
people in the mid to late 60s that they continue to support ... but the
individuals are due to retire at any moment. Their use of MVS-based
infrastructure can't be duplicated on other available platforms. Porting
the applications and database would result in a significantly less
efficient implementation at increased cost.  There has been activity since
the early 90s to migrate to 3-layer architecture for some of the
applications ... to possibly mitigate intensity of future conversion effort
(when both people retire).

We've also have had converstations with random gov. CIOs commenting about
number of studies by outside consulting companies brought in with agenda to
show MVS is less efficient, more costly and less agile ... than other
platforms. The issue that has been brought forward to associated executives
is that retirement age of their (MVS) senior data processing staff is on
the top ten list of risks faced by the organization (not necessarily a cost
issue ... but at least, their experience can't be backfilled at any cost).
This is similar to projections that it might take 20 years to do another
saturn/apollo moon effort ... compared to less than 10 years the first time
.. even assuming, in theory, the documentation and experience of the first
effort could be drawn on (which a lot of people claim to have been lost).

another part of the backfill issue is talking to younger people who realize
that with a couple months of HTML experience ... they can get a better
paying job building web sites than what they could get doing MVS support
with 5-10 years experience.

random references:

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

At 11:33 AM 1/18/00 -0600, Tom Schmidt wrote:

I don't doubt that you were told this as the reason but I don't believe
it to be a valid reason.  Consider that they knowingly replaced
something that worked well with something else not as good because they
couldn't hire replacements.  Why wouldn't they attempt to grow the
talent in-house?  If they *did* attempt it and failed, why did they
fail?  My bet is that they were attempting to keep the salaries
artificially low - much lower than the local or regional competition.

I'm entertained by the suggestion that local financial organizations
were paying better, since most financial organizations pay lower in my
experience.  (Banks think they understand money so they don't give it
away, manufacturing companies think they understand their product so
they don't give it away, etc.)

<rant>
I've only met one decent HR person in my 25+ year career.  The rest were
hacks who did more damage to their company than anyone in IT ever could.
</rant>

Tom Schmidt
Madison, WI

On Fri, 14 Jan 2000 19:28:07 GMT, in bit.listserv.ibm-main Anne & Lynn
Wheeler wrote:
>I've talked to a number of large organizations that retired MVS and
>converted to something else not as good. Reason given was that their
>MVS staff was retiring and they weren't able to backfill the slots.
>
>In many cases, they found they weren't able to compete with financial
>organizations for scarce resource. Even in some financial
>organizations, they identify in the top five business risks critical
>MVS staff with over 30 years (nearing retirement age, kids are all
>thru school, house paid for, and it is getting difficult to motivate,
>even with significant salary raises).

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

SmartCard with ECC crypto

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SmartCard with ECC crypto
Newsgroups: alt.technology.smartcards
Date: Mon, 24 Jan 2000 17:44:25 GMT

we announced/demo'ed X9.59 along with AADS age/address & some AADS
RADIUS (i.e. authenticate using AADS when connecting to your ISP
instead of password) at worldwide retail banking show in Miami last
month ... and they it was demo'ed in at least three booths at RSA
conference last week. Card used for the AADS signature transactions
was an ECC smartcard.

for reference see

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

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

IBM 360 Manuals on line ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM 360 Manuals on line ?
Newsgroups: alt.folklore.computers
Date: Tue, 25 Jan 2000 04:35:36 GMT

also principles of operation was one of the first to be done with
script & then GML (i.e. precursor to SGML & HTML).

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

SmartCard with ECC crypto

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SmartCard with ECC crypto
Newsgroups: alt.technology.smartcards
Date: Wed, 26 Jan 2000 04:30:31 GMT

"J Hartmann" <jhartmann@bigfoot.com_NOSPAM> writes:

But where could I get this ECC card?

jh

certicom was part of the announcement referenced in the prior postings
and mentioned in the press release pointed to by the URLs.

their website is

http://www.certicom.com/

list of their smartcard products is at

http://www.certicom.com/smartcards/index.htm
http://web.archive.org/web/19990428144441/http://www.certicom.com/smartcards/index.htm

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

"Trusted" CA - Oxymoron?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Trusted" CA - Oxymoron?
Newsgroups: alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss,sci.crypt
Date: Wed, 26 Jan 2000 05:04:57 GMT

Lots of times, especially involving privacy issues ... the only thing
that needs to be authenticated is if the entity authorized to perform
the requested function ... in which case a generalized "identity"
certificate (certifying some binding between a public key and some
misc. personal information) can be orthogonal to the objective at hand
... and possible may represent a compromise unnecessarily divulging
personal information.

In a typical retail scenerio ... the merchant doesn't actually need to
know who you are when you present a credit card ... the merchant
really wants to know whether they will be paid or not.

There has also been misc. discussion of EU privacy guidelines about
making retail electronic financial transactions as anonymous as cash
... i.e. a credit/debit card presented to a merchant would contain
no name &/or require any other identification information. It would
similarly work in non-face-to-face retail electronic transactions
(aka internet, e-commerce) with no identity information exchanged in
the transaction.

In the PKI world for financial institutions, this has been translated
into relying-party-only certificates ... i.e. a certificate
that only carries the public key and the account number for financial
transactions (in order to avoid unnecessarily divulgy privacy
information). However, for financial transactions it is easily shown
that since the original of the certificate resides in the account
record ... it is redundant and superfluous for the consumer to return
their copy of the certificate as part of every financial transaction
to their financial institution (and doing so can even unnecessarily
increase the infrastructure's systemic risk).

misc. references:

http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
http://www.garlic.com/~lynn/aadsm3.htm#cstech13
http://www.garlic.com/~lynn/aadsm3.htm#cstech8
http://www.garlic.com/~lynn/aadsm2.htm#scale
http://www.garlic.com/~lynn/aadsm2.htm#inetpki
http://www.garlic.com/~lynn/aadsm2.htm#integrity
http://www.garlic.com/~lynn/aadsm2.htm#account
http://www.garlic.com/~lynn/aadsm2.htm#privacy
http://www.garlic.com/~lynn/aadsm2.htm#stall
http://www.garlic.com/~lynn/aadsmore.htm#hcrl3
http://www.garlic.com/~lynn/aadsmore.htm#schips
http://www.garlic.com/~lynn/aadsmore.htm#vpki
http://www.garlic.com/~lynn/aadsmore.htm#killer0
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2
http://www.garlic.com/~lynn/aepay3.htm#x959discus

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

"Trusted" CA - Oxymoron?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Trusted" CA - Oxymoron?
Newsgroups: alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss,sci.crypt
Date: Wed, 26 Jan 2000 20:07:15 GMT

the other issue is what does a certificate convey?

standard certification represents some vetting of information that
occured at the time the certificate was manufactured. It does a poor
job when timely information &/or information aggregation is involved.

oSCP goes a little way torwards providing timely indication of whether
the stale information is still valid or not (it is a direct analoge of
numerous distributed caching algorithms developed in the '70s and '80s
for things like files &/or pieces of files; the difference is that
most of these caching infrastructures not only had timely invalidation
protocol ... but also timely cached information refresh semantics).

One of the possible certificate targets was something akin to the
semantics of a check with a limited signing limit (i.e. a check that
carried printing that said it was limited to $5000). However, as was
discovered in the 60s & 70s ... this lacked timely information &
information aggregation capability ... i.e. somebody did a one million
dollar order by signing two hundred $5000 checks. The 60s & 70s
started to see emerging online transaction operations which provided
both timely information & information aggregation paradigm support.

The certificate paradigm is targeted at offline, atomic operations
(i.e. infrastructures not requiring timely information, online
information, and/or information aggregation). Attempting to actually
translate certificates into something like a offline, electronic check
transaction scenerio ... would be equivalent to reversing the online
direction to an offline pre-60s paradigm.

In some cases (as per prior note), CAs may be authenticating the wrong
information (i.e. leading to things like privacy compromises).  In
other cases, a CA can absolutely authenticate some piece of
information at some point of time ... but having manufactured a
certificate at some point in the past with stale information, its
application is irrelevant to online, timely information, and/or
information aggregation paradigm. The trust isn't in question but
infrastructure failures occur because the paradigms didn't intersect
(aka making sure that nobody could fudge the "$5000" on a signing
limit check to read "one million" ... when the problem was the use of
two hundred $5000 checks).

similar thread:

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

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

Vanishing Posts...

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vanishing Posts...
Newsgroups: wash.politics,seattle.general,seattle.politics
Date: Wed, 26 Jan 2000 23:01:52 GMT

for instant here is the path information I see with respect to the
most recent post (that i've seen):

Path: news-west.eli.net!news-chi-1.sprintlink.net!
      news-central.sprintlink.net!news-peer1.sprintlink.net!
      news.sprintlink.net!router1.news.adelphia.net!
      news.hyperioncom.net!cyclone.news.idirect.com.MISMATCH!
      newsfeed.direct.ca!howland.erols.net!newsfeed.skycache.com!
      news.eskimo.com!aaronbego

I had worked on some precursor technology to listserv in the late
'70s.  A listserv/majordomo server might be running on a machine with
no other function ... and it may only be supporting a single mailing
list. The listserv mail daemon accepts a direct TCP session for
incoming mail and then sends back a direct TCP session to the mailer.
The most likely bottleneck is the number of people that may have
subscribed to a specific mailing list which translates into how many
pieces of mail the server has to send out. For small mail lists this
isn't a consideration ... but it becomes quite a problem if you start
dealing with thousands of people on a mailing list.

The newsgroup server infrastructure will compensate for large number
of readers/subscribers by having a store&forward, distributed
server infrastructure (instead of one mailer sending everything to
everybody ...  it only has to forward stuff to a few select select
subscribers which in turns forward to their subscribers). The above
path gives the forwarding information from the point the lastest
posting contacted the usenet infrastructure to the point it arrived in
my part of the usenet infrastructure. While the infrastructure is
significantly more efficient and handly significantly larger volume
than the listserv/majordomo operation ... there are latencies
associated with the efficiency improvement.

Typically, any specific forwarding host may operate in batch mode ...
i.e. connecting for usenet post forwarding once every 15 minutes and
acquiring all new posts for all newsgroups (say collecting all new
postings in support of 40,000 different newsgroups ... not just a
simple, single mailing list like many listserv/majordomos operate).

In the above path for the most recent posting ... each "bang"
(i.e. "!")  separates a store&forward node and can possibly
represent anywhere from seconds to 15-30 minutes.

Many of the "local" newsgroups tend to be area related (for instance
the seattle hierarchy) ... and have relatively few hops between most
of the people participating. As people from a wider area attempt to
participate in local newsgroups exchanges ... they will tend to be
much further away in terms of "hops" and "latencies". I would expect
that most of the participants in the seattle hierachy are relatively
few hops away from each other and experience low latencies ... people
participating from a much wider area will (with more hops) , of
course, experience much larger latencies.

Some of the broadcast technologies (satellite, tv blanking interval)
have been use to distribute newsgroups postings (something that isn't
really feasable with the mailing list paradigm) to shorten the latency
with propagating newsgroup information. I had helped with one such
implementation and co-authored an article in the summer of '93 that
appeared in boardwatch magazine (at the time targeted primarily to the
BBS market, it use to be online ... but their website now only has
online issues going back to '95).

In any event, mailing list paradigm can have low latencies when
serving small populations ... moving into the newsgroup paradigm to
obtain significant increase in efficiencies will introduce additional
latencies (having nothing to do any server efficiency).

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

"Trusted" CA - Oxymoron?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Trusted" CA - Oxymoron?
Newsgroups: alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss,sci.crypt
Date: Fri, 28 Jan 2000 05:15:14 GMT

john@nisus.com (John G. Otto) writes:

Digicash's scheme provides both anonymity and assurance of
the transfer.  The only draw-backs WRT privacy are that they
have a way to report the transactions and is subject to a
traffic monitoring.

for the most part, the bank doesn't care what your DNA is ... they
just care that only the person that open/own the account & is
authorized to use the account ... is the person that uses that
account. If a CA binds a person's DNA identity in a certificate to the
public key ... it doesn't mean anything to the bank, unless the bank
has also used DNA for opening the account.

The current bank business process is to record a shared-secret
... typically person's mothers maiden name when the account is opened
... and asks for that in non-face-to-face transactions.

That same business process can be upgraded to record the person's
public key. The bank then verifies digital signatures on
non-face-to-face electronic transfers/transactions with the recorded
public key ... effectively the same business process that uses mothers
maiden name to verify transactions.

No CA is required ... and no identity verification is required by 3rd
parties ... and no new business processes are required ... and no
trusted 3rd party liability is created ... and no CA policies &
practices ... current business processes just have technology
upgrades.

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

"Trusted" CA - Oxymoron?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Trusted" CA - Oxymoron?
Newsgroups: alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss,sci.crypt
Date: Fri, 28 Jan 2000 17:55:18 GMT

let's put identity certificates another way ...

the transfer request comes in via smime/email, the body of the message
contains the account number and the directions. this is signed and has
a certificate attached. the bank takes the certificate ... and
authenticates the certificate with the CA's public key ... which comes
from some certificate that it has laying around ... which also may
need authenticating (the trust chain not only has all of their
certificates ... but may also require OCSP transactions).

in any case, eventually after the attached certificate is
authenticated, the message gets authenticated with the public key. THe
account number from the body of the message is then used to look up
the account record. The "name" of the account owner is retrieved from
the account record ... and needs to be compared against some
information in the body of the identity certificate. Supposedly if the
character string in the body of the message matches the character
string on record in the account record ... then the transaction is
supposedly valid.

The CA infrastructure not only has to absolutely bind some set of
identity information to the public key going into the certificate
... but that set of information also has to have some exact match with
the owner "string" in the bank record. The CA infrastructure can
absolutely be sure that they have correctly bound the identity
information ... and the transaction still won't work because the
identity strings don't exactly match (the one in the certificate and
the one in the account record).

So, some number of banks have looked at issuing relying-party-only
certificates ... for privacy and liability issues (as well as
relevency, will the strings match). The "identity" bound in the
certificate is just the bank account number. That slightly simplifies
the process ... since there is no strings to mismatch ...  after
verifying the certificates in the trust hierarchy ... the account
number is taken directly from the transaction and reads the account
record (and only the account numbers have to match).

The next step is realizing that the whole CA infrastructure allows
that if the relying party is known to have the trust hierarchy CA
certificates (and/or can expect to easily obtain them) ... the
certificate(s) don't have to be transmitted on every transaction
(i.e. the CA certificates to validate a individual's certificate is
assumed to be already at the relying party ... and/or the relying
party can easily obtain it). In the case of relying-party-only
certificates, the bank has stored the original certificate in the
account record and sent a copy to the individual. Then under current
CA infrastructure policies, if the relying party can be assumed to
have a copy of the certificate(s) (&/or can easily obtain them, they
don't have to be retransmitted) ... then the individual signing the
transaction doesn't have to retransmit copies. In this case, the
relying party is known to have all certificates, including the
original of the individuals certificate.

So, the bank just pulls the account number from the transaction, reads
the account record, pulls the public key out of the account record,
and uses it to validate the digital signature on the transaction.

For efficiency purposes the public key will be stored in unencoded
form in the account record. Certificates are defined in encoded for
for interoperable network transmission, but have to be decoded in
order to access the fields, the bank can store the unencoded
certificate fields in the account record since the ASN.1/encoded form
is only needed for interoperble transmission & revalidation of the
CA's signature. Since they create the original of the certificate,
they have signed it ... just for redundancy they could reverify their
own signature at certificate manufactur time, before decoding and
loading into the account record.

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

"Trusted" CA - Oxymoron?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Trusted" CA - Oxymoron?
Newsgroups: alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss,sci.crypt
Date: Fri, 28 Jan 2000 18:42:10 GMT

... and an option ... the relying-party-only bank may determine that
it isn't even necessary to transmit a copy of the certificate back to
the individual. The individual goes thru the public key RA process
with their bank. The bank does the RA bit, then manufactures a
certificate by encoding the fields and signing them. The bank then
verifies the signature on the newly minted certificate, decodes it and
stores the decoded fields in the account record. If the bank decides
there is never a business scenerio requiring the individual to
transmit the relying-party-only certificate on a relying-party-only
transaction, the bank won't bother to transmit a copy of the
certificate to the individual. The bank just keeps the original on
file (in its unecoded form).

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

"Trusted" CA - Oxymoron?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Trusted" CA - Oxymoron?
Newsgroups: sci.crypt
Date: Sun, 30 Jan 2000 22:33:36 GMT

tmetzinger@aol.comnospam (Timothy M. Metzinger) writes:

as many people have indicated, for a transfer of wealth, the identities of the
individuals aren't important, only the identities of the two containers ("from"
and "to") matter.

But for signed documents, legal briefs, title transfers, and other
applications, it IS important to verify individual identities.

While many commercial CA's don't verify identity, some do... Digital Signature
Trust Corp, Verisign, Baltimore (formerly GTE CyberTrust), and the DOD CA's do
have certificate policies where they do a face-to-face registration of
individuals, and stand behind the certificate's binding.

note that manufactured certificates done at some time in the past is
relying on some consensus/domain about the information being
certified.

(not having) identity is issue in many circumstances. also, to some
extent a business process would come down to doing a string compare
against some arbritrary, generalize "identity" representation carried
in sort of string embedded in a manufactured certificate and so other
arbritrary identity representation string (presumably if the string
compare match ... then some business process can proceed).  There have
been recent SSN privacy postings citing both same SSN as well as same
first/last name (i.e. same SSN number given out to two different
people with same first/last name).

financial transfers need near-time certification associated with
specific domain (and circumstances like current account balance and/or
outstanding debt) by institutions carrying at least some liability
associated with the process (as opposed to random 3rd parties).

simplified certificates have been transition from offline/paper to
offline/electronic. however, in growing number of even document
transactions (not limited to purely financial transactions) there is
more & more of a move to online/electronic (pretty much anything
involving value exchange and/or liability).

Effectively starting to see transition to real time certification
within the domain/context of the specific operation taking place
... especially when the certifying agency carries some liability, risk
& handling filing (transaction is registered in some central filing
place ... so the repository also does a form of real time
certification).

Example is title insurance company handling title transfers, they will
certify individual(s) within the context of the title transfer & just
for the specific title transfer (in part because they carry liability
on each specific title transfer ... so the idea of a "blank check"
certificate for an arbritrary & unknown number of title transfers
involving arbritrary & unknown value is not likely).

Stale certificates represent much more of transition from
offline/paper to offline/electronic ... but I would expect to see much
more real-time certification in transition to online/electonic, even
for document signing, especially where there is value/liability
involved and especially when some sort of filing is required. Each one
becomes a specific, known, & likely time-stamped certification ... as
opposed to a blank check certification/certificate that might be used
in an arbritrary & unknown number of times involving arbritrary &
unknown value (businesses tended to not like unknown/unbounded
liability/risk).

The play for offline/electronic identity certificates would tend to be
when value proposition seems to be negligible risk/liability (say
government employees within legislated context) &/or an online+filing
infrastructure represents significant percentage of value proposition.

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

Historically important UNIX or computer things.....

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Historically important UNIX or computer things.....
Newsgroups: alt.folklore.computers
Date: Fri, 04 Feb 2000 18:18:49 GMT

i developed a system build process that would dump the kernal to tape
...  and since there was so much empty space still on the tape
... dump everyting needed to rebuild the kernel, procedures, source,
execution environment, procedures, etc.

Periodically would "archive" a tape and possibly make copies in
triplicate (and did full tape copes from 800bpi to 6250bpi ... and
then from 6250bpi to 3480 cartridges). Problem I had was that we had a
data center where the operators would randomly take tapes out of the
library and use them for scratch. Lost a bunch of early PLI stuff
(even when replicated on three different tapes) and only had trivial
amount of the early build tools (again done in triplicate) when
Melinda Varian was looking for early examples.

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

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

Historically important UNIX or computer things.....

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Historically important UNIX or computer things.....
Newsgroups: alt.folklore.computers
Date: Fri, 04 Feb 2000 20:45:46 GMT

oh, and I had done some early stuff as an undergraduate on operating
system monitoring supporting dynamic adaptive performance
optimization. The archived stuff was referenced in the early 70s in a
legal matter involving some sort of system monitoring patent.  When a
similar legal matter reared its head again in the mid-80s ... all
three tapes containing replicated copies of the original source had
been trashed by data center operations.

to the extent stuff survived ... were on tapes that I had copied,
checked out of the library and kept under lock & key in my office.

random reference:

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

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

TLS: What is the purpose of the client certificate request?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TLS: What is the purpose of the client certificate request?
Newsgroups: sci.crypt
Date: Mon, 07 Feb 2000 16:23:29 GMT

Anuj Seth writes:

Hi,

> Yes, the server certificate authenticates the server and the client
> certificate authenticates the client.  I don't understand your final
> question about authenticating the user.

That's what I thought as well! About, the question you didn't understand
let me rephrase it -- The server requests the client for the
certificate. The client sends the certificate across to the server. Now,
how is the server supposed to authenticate the client? Basically, the
server should be able to access the CA to get the CA's public key. The
CA's public key will be used to authenticate the user (If I'm correct).
I've read the X.509 standard but couldn't figure out how to connect to
the CA to get the CA's public key. Could someone let me know how it is
to be done?

at least some of the targets are controlled environments ... where there
is only one (or a few) known CA(s) for client certificates and the
CA's public key is preloaded into the server.

This is somewhat analagous to the reverse ... where the server CA
public keys have been preloaded into the client browswers when the
browsers were manufactured.

The server may only be using the client certificate to validate
membership in the allowed community (client demonstrates that it owns
a valid certificate for access purposes). Validating client membership
just involves validating the certificate and validating that something
the client signs can validate with the public key in the certificate.

Actually validating the client typically would require verifying
something more than membership assertion (like something from the
contents of the signed information) against some local infrastructure
(like an account record).

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

question about PKI...

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: question about PKI...
Newsgroups: sci.crypt
Date: Mon, 07 Feb 2000 17:13:16 GMT

palmpalmpalm@aol.com (Palmpalmpalm) writes:

Hi, does anybody kindly answer my question?

What method does the PKI product provide for mobile users?
When users move to another computer, do they have to bring their own private
key and certificate always?

Thanks in advance.

mobile software versions can be as simple as a floppy disk that can
copies private keys from one PC to another PC.

some forms of digital signatures strive for showing only a single
person has access to the use of the private key. demonstrating this
can require showing that nobody else had access &/or could have copied
the private key. One way for achieving this goal is an environment
where the private key is encapsulated inside a hardware token and it
is extremely difficult for anybody (even the hardware token owner) to
directly access the private key (the hardware token uses the private
key for digital signing ... but there is no function for reading the
private key; showing that nobody has direct access to the private key
is superset of showing nobody else has access).

Showing that nobody can directly access the private key ... then it
reduces to trying to show that all digital signatures can only be
performed when the hardware token is in their possession (modulo
tricking people into using their hardware token).

A hardware token can also be mobile & interchangeable (like a card)
that is moveable from one device to another (like between different
PCs, PDAs, & cellphones). A hardware token could also be physically
housed in a PDA or cellphone ... and when used in conjunction with a
PC ... the PC and the hardware token communicate via the PDA/cellphone
(using proximity contactless protocol, infrared, something like
"bluetooth", more traditional wireless, or even some physical adapter
connection).

One objective of the AADS (sometimes referred to as PKNI ... or public
key, no certificates) parameterized risk management is establishing
the integrity of digital signing mechanism (minimizing some of the
risk unknowns when performing authorization functions ... and/or being
able to scale the integrity compareable to the authorization
requirements). Rather than just saying that the digital signature
could have come from a hardware token ... having a high level of
confidence that the digital signature could have only originated from
a specific hardware token with verifiable integrity characteristics
(like an audit trail between the time the hardware token chip was
manufactured and the time the public/private keys were generated & the
public key was recorded).

misc. bluetooth reference:

http://www.gartner.com/public/static/hotc/hc00082960.html
http://www.bluetooth.com/

misc. aads reference:

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

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

TLS: What is the purpose of the client certificate request?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TLS: What is the purpose of the client certificate request?
Newsgroups: comp.security.misc
Date: Mon, 07 Feb 2000 20:05:06 GMT

Anuj Seth writes:

Hi,

> > If this is the reason, how does one authenticate the user??

The server requests the client for the certificate. The client sends the
certificate across to the server. Now, how is the server supposed to
authenticate the client? Basically, the server should be able to access
the CA to get the CA's public key. The CA's public key will be used to
authenticate the user (If I'm correct). I've read the X.509 standard but
couldn't figure out how to connect to the CA to get the CA's public key.
Could someone let me know how it is to be done?

the server doesn't request a copy of the certificate for
authentication, the server makes a request for a digitally signed
message for authentication purposes. One method that the server has
for obtaining the public key for authenticating a digital signature is
by attaching the corresponding public key certificate.  But then, in
order to verify the public key certificate, the CA's public key needs
to be obtained. This can be done by preregistering the CA's public key.

It is possible to also preregister the client/individual's public key
(in much the same way that CA's public keys can be preregistered).

the membership & client specific authentication can be done with
digital signature and no certificates being transmitted ... where the
public key is registered in place of a password in something like a
radius database for the client/user. then instead of using
userid/password for authentication (for either PPP &/or webserver
authentiation), the client digitally signs something and the server
does a radius transaction to authentication the client's
signature. This would handle digital signature authentication for
membership authentication, client-specific authentication, as well as
timely operation authentication (is the client still authorized for
the connection as of this moment) and does it within the dominate
currently deployed client authentication process (radius).

For just determining a client membership authentication (as opposed to
client authentication) ... giving the client a membership certificate
and recording the CA's public key at the server is pretty
straight-forward. Getting into actual client authentication with
timely information about current status gets into some sort of account
record. As soon as an account record becomes involved, then it is more
straightforward to record the client's public key directly and do away
with the certificate transmission portion of the operation.

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

TLS: What is the purpose of the client certificate request?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TLS: What is the purpose of the client certificate request?
Newsgroups: comp.security.misc
Date: Mon, 07 Feb 2000 20:24:18 GMT

misc. reference ...

RFC 2246              The TLS Protocol Version 1.0          January 1999

   Structure of this message:
       opaque ASN.1Cert<1..2^24-1>;

       struct {
           ASN.1Cert certificate_list<0..2^24-1>;
       } Certificate;

   certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

   The same message type and structure will be used for the client's
   response to a certificate request message. Note that a client may
   send no certificates if it does not have an appropriate certificate
   to send in response to the server's authentication request.

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

IBM RT PC (was Re: What does AT stand for ?)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM RT PC (was Re: What does AT stand for ?)
Newsgroups: alt.folklore.computers
Date: Tue, 08 Feb 2000 17:57:57 GMT

note also that PC/RTs were the NSFNET1 backbone routers. A PC/RT had
440kbit/sec adapter cards ... three RT/440kbit streams were channeled
into an IDNX (basically a private phone switch) T1. Each NSFNET1
backbone site had racks & racks of PC/RTs handling 440kbit/sec streams
connected to IDNX box running T1 connections between backbone
sites.

PC/RT ran a virtual machine supervisor (written in pl.8 & somewhat
adopted from display writer follow-on project) under which ran a
highly modified version of AT&T system 5.2. One of the porting
problems to AIX on PC/RT was device drivers since they weren't
actually interfacing to the bare hardware.

AOS started out as project to port BSD to 370 mainframe and then was
retargeted to PC/RT.

misc. romp, pc/rt & aos references:

http://www.garlic.com/~lynn/98.html#25
http://www.garlic.com/~lynn/98.html#26
http://www.garlic.com/~lynn/98.html#27
http://www.garlic.com/~lynn/99.html#2
http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/99.html#64
http://www.garlic.com/~lynn/99.html#65
http://www.garlic.com/~lynn/99.html#129
http://www.garlic.com/~lynn/99.html#146

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

APPC vs TCP/IP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: APPC vs TCP/IP
Newsgroups: bit.listserv.ibm-main
Date: Wed, 09 Feb 2000 00:08:06 GMT

minor mainframe tcp/ip reference:

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

in the early history, I've talked to people who claimed that
after having done some MVS tcp/ip implementation they were
instructed to recode so that it is much slower than sna/appc.

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

APPC vs TCP/IP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: APPC vs TCP/IP
Newsgroups: bit.listserv.ibm-main
Date: Wed, 09 Feb 2000 08:10:40 GMT

the 60s/70s packet prtoocol was the arpanet protocol that the IMPs
talked. The Work on "internet protocol" started sometime int the 77/78
timeframe. TCP appeared earlier but layered on top of the IMP/arpanet
host-to-host stuff.

internet protocol (as opposed to the IMP-based arpanet stuff) first
appears as standard document RFC760 published 1/1/1980

many TCP/IP products were based on bsd4.3 tahoe that was done in 87-89

by comparison, one could make the claim that no "networking" occurs at
all in SNA prior to APPN (circa 10/86) since that is the first
appearance of a "network layer" being implemented (ala OSI).

misc. references

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

http://www.garlic.com/~lynn/internet.htm
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/99.html#40
http://www.garlic.com/~lynn/99.html#48
http://www.garlic.com/~lynn/99.html#112

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

Correct usage of "Image" ???

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Correct usage of "Image" ???
Newsgroups: alt.folklore.computers
Date: Fri, 11 Feb 2000 14:42:08 GMT

misc. on page replacement ... circa 1968 ... of course there was atlas
on others before.

http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/93.html#4
http://www.garlic.com/~lynn/93.html#5
http://www.garlic.com/~lynn/94.html#1
http://www.garlic.com/~lynn/96.html#0a
http://www.garlic.com/~lynn/98.html#54
http://www.garlic.com/~lynn/99.html#18

this was on cp/67 which was port from cp/40 circa 65 or 66. some of
information on virtual memory is history paper at:

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

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

APPC vs TCP/IP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: APPC vs TCP/IP
Newsgroups: bit.listserv.ibm-main
Date: Thu, 10 Feb 2000 03:26:08 GMT

we use to rib some of the people working on appn that instead of
trying to force-fit networking into SNA that they should work on real
networking in tcp/ip; that the SNA crowd wasn't going to appreciate
their efforts. when it came to announce APPN ... the SNA group, in
fact, non-concurred ... and there was a 6 week delay while the
announcement letter was re-written so that APPN was quite clearly
differentiated from SNA (i.e. nobody should be confused about SNA
supporting networking).

Announcement letter did make it out in oct of 1996 ... some month I
was giving presentation at the SNA ARB (architecture review board)
meeting in raliegh.

misc. references:

http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#70
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/99.html#201
http://www.garlic.com/~lynn/99.html#12
http://www.garlic.com/~lynn/99.html#36

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

Hotmail question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Hotmail question
Newsgroups: comp.security.misc
Date: Sun, 13 Feb 2000 17:56:29 GMT

dialins are typically dynamically assigned IP addresses (and/or slaved
to the incoming modem) ... one possibility is the packet is left-over
from previous assignee of that IP addresses that had dropped their
connection to the ISP.

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

OS/360 JCL: The DD statement and DCBs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS/360 JCL: The DD statement and DCBs
Newsgroups: alt.folklore.computers
Date: Mon, 14 Feb 2000 17:11:08 GMT

Lars Poulsen writes:

Some of the utility programs did some really bizarre things with
their DCBs, including stuffing parameters they had read from their
SYSIN DD's into the DCB before opening the file. But they still
had to have a SYSUT1 DD card there, even if there was no
information on it.

asmg read jfcb (job file control block) macro could pull up the
internal representation before the open.

mostly i remember it being used by "monitors" ... i.e. programs that
simulate stripped down job schedular for compile, load & go. Our shop
converted 709 ibsys doing student fortran jobs measured in jobs per
second (it was tape-to-tape, with 1401 acting as unit record front
end) to OS/360 PCP 9.5 doing the same workload measured in minutes per
job.

adding hasp got it down to jobs per minute, but a 30 second 3-step
fortran complie, lked, & go was still almost all job scheduler time. a
monitor was tested that got it down to a couple seconds per student
job ... but it was about the same time we installed watfor ... which
got the 360/65 thruput on student fortran jobs back to finally better
than the 709 ibsys

random references:

http://www.garlic.com/~lynn/93.html#1
http://www.garlic.com/~lynn/94.html#18

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

OS/360 JCL: The DD statement and DCBs

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS/360 JCL: The DD statement and DCBs
Newsgroups: alt.folklore.computers
Date: Mon, 14 Feb 2000 17:17:10 GMT

also, another interesting reference:

http://jmaynard.home.texas.net/hercos360/

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

RealNames hacked. Firewall issues.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RealNames hacked. Firewall issues.
Newsgroups: comp.security.firewalls,comp.security.misc,comp.security.unix
Date: Mon, 14 Feb 2000 23:12:35 GMT

Wally Whacker writes:

You guys missed the point. I didn't say credit cards were perfect. I
said a verifiable payment scheme gives the consumer much less ability
to undo a bad transaction. Why not argue that point? It's a pretty
scary scenario. Why have digital signatures if their purpose isn't to
verify the actual source of a transaction?

Plaintiff: "Mr Jones bought this car from us. We have his digital
signature on the transaction."

Defendant: "Your Honor, I didn't make this charge".

Judge: "You signed it. Your digital signature is on it. Judgement in
favor of plaintiff. Next case."

Is that your preferred scenario?

If your private key becomes equivalent to your signature, what happens
when your private key gets ripped off? Ooops. Now you are really
f**ked.  It's like someone having your fingerprints on their fingers.

At some point the human factor always enters in. How are you going to
buy these "phone cards"? Cash? Carrying a lot of cash around is even
more dangerous that using a credit card. At some point there is always
a human involved and you better thank your stars for that. If machines
were able to 100% rule the financial transactions universe without
human ability to intervene then hacking would truly become the most
profitable profession.

X9.59 is industry draft standard for end-to-end digital signature
authentication for all electronic retail payments (credit, debit,
internet, non-internet, etc). it operates within the existing payment
business processes for authentication and extends various forms of
parameterized risk management to the digital signature paradigm.

Specifically, it doesn't say that your card can't be ripped off
... &/or your private key can't be stolen ... but tries to establish a
parameterized infrastructure as to the risk associated with such
things happening given the known integrity parameters surrounding the
private key and digital signing environment.

PC-based software private key & signing environments have a lot higher
risk than a hardware token based environment. A hardware token with no
activation process has higher risk than a PIN-activated hardware
token. A PIN-activated hardware token has higher risk than a
biometric-activated hardware token. Kinds of cryptography, length of
keys, kinds of chips, whether there is audit trail on specific chip
back to the foundry, etc are also all risk & integrity issues.

misc. X9.59 references at:

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

specific references ... multiple posting thread at:

http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/aadsm2.htm#strawm1

other threads.

http://lists.commerce.net/archives/ansi-epay/199901/msg00014.html

misc identity vis-a-vis authentication issues:

http://www.garlic.com/~lynn/aadsmail.htm#vbank

part of the issue might be characterized with the problem associated
with creating a trusted third party infrastructure that provides some
meaningful information binding (in manufactured certificates) that would
carry some meaning to relying parties.

Businesses & financial infrastructures have used account records as
information binding paradigm for eons. X9.59/AADS can bind a public
key in an account record for doing digital signature authentication
... and it isn't necessary to step outside of the existing business
processes and/or legal infrastructure to determine what that means
(i.e. integrity is improved and risk is lowered compared to some
currently deployed technology ... but that doesn't change the business
relationships and/or the business processes).

It is much harder problem to try and establish an implied business
meaning between an arbitrary 3rd party and relying parties which have
no direct business relationship, especially if somebody has to be
motivated to exchange some money with arbitrary 3rd party in return
for a manufactured certificate.

In general with retail transactions disputes, the burden of proof has
been on the entities with the most resources (i.e. merchants & banks).
There is discussion not only about making a digital signature
equivalent to a real signature ... but also creating the sense of
non-repudiation and shifting the burden of proof from the business
entity with the most resource (merchants & banks) to the entity with
the least resource (typically the consumer). It would seem that such a
shift also changes some of the retail value proposition ... possibly
creating value opportunity justifying payment of money to arbitrary
3rd parties in exchange for certificates (although it would seem
somewhat ironic that consumers would be the ones to pay for the
privilege of giving up some of their rights).

The AADS digital authentication framework has also been applied to
non-financial things ... like radius ... i.e. register a public key in
the radius authentication database and instead of doing "radius"
userid/password authentication for internet/isp connectivity ... do
radius userid/digital signature authentication for internet/isp
connectivity. It is also straight-forward to add the same radius
authentication process to webserver client authentication (i.e.
instead of doing RYO client authentication stubs in the webserver,
invoke radius).

This AADS framework approach was rather than treating digital
signatures as a new business and authentication paradigm
... intergrate digital signatures into existing business processes as
an authentication technology upgrade (rather than forcing a paradigm
business shift, just treat it as a technology enhancement ... on par
with prior events like forcing passwords to be 8+ characters & were
resistant to various known password pattern exploits & guessing).

--
Anne & Lynn Wheeler   | lynn@garlic.com