List of Archived Posts

2005 Newsgroup Postings (09/18 - 09/30)

HASP/ASP JES/JES2/JES3

Effective micropayments

Article in Information week: Mainframe Programmers Wanted

winscape?

winscape?

What ever happened to Tandem and NonStop OS ?

What are the latest topic in TCP/IP

HASP/ASP JES/JES2/JES3

What ever happened to Tandem and NonStop OS ?

What ever happened to Tandem and NonStop OS ?

Tapes (3590) and VM

Securing Private Key

What ever happened to Tandem and NonStop OS ?

IPSEC with non-domain Server

What ever happened to Tandem and NonStop OS ?

HASP/ASP JES/JES2/JES3

HASP/ASP JES/JES2/JES3

Ethernet, Aloha and CSMA/CD -

Ethernet, Aloha and CSMA/CD -

HASP/ASP JES/JES2/JES3

Ethernet, Aloha and CSMA/CD -

Ethernet, Aloha and CSMA/CD -

tcp-ip concept

Logon with Digital Siganture (PKI/OCES - or what else they're called)

What ever happened to Tandem and NonStop OS ?

Intel strikes back with a parallel x86 design

What ever happened to Tandem and NonStop OS ?

What ever happened to Tandem and NonStop OS ?

tcp-ip concept

IPSEC wireless router ?

HASP/ASP JES/JES2/JES3

Intel strikes back with a parallel x86 design

HASP/ASP JES/JES2/JES3

Intel strikes back with a parallel x86 design

How To Abandon Microsoft

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Callable Wait State

Intel strikes back with a parallel x86 design

How To Abandon Microsoft

Intel strikes back with a parallel x86 design

Instruction Set Enhancement Idea

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

What ever happened to Tandem and NonStop OS ?

HASP/ASP JES/JES2/JES3

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Sun, 18 Sep 2005 11:28:30 -0600

Anne & Lynn Wheeler writes:

another history of hasp & jes2 (share presentation)
http://www.redbug.org/dba/sharerpt/share79/o441.html

JES2 multiaccess SPOOL was preceded by similar mods written at NIH and
Mellon. Likewise, NJE was preceded by user written modifications at
the University of Iowa and Triangle Universities Computation Center.

ref:
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3

in fact, folkore is that HASP/JES2 nodes on the internal network
... before NJE was released to customers ... still carried "TUCC" in
cols. 67-70 of the source.

before NJE was released, it was being used in the corporate internal
network (which was larger than arpanet/internet from just about the
beginning until possibly mid-85)
http://www.garlic.com/~lynn/subnetwork.html#internalnet

the internal network was primarily based on networking code
developed at science center
http://www.garlic.com/~lynn/subtopic.html#545tech

and effectively contained a kind of gateway architecture built
into every node from the start.

this immensely assisted in dealing with the NJE nodes. basically the
NJE support used the hasp psuedo device table to define network nodes
(one byte, 256 entries). a typical NJE configuration might have 60-80
defined psuedo-devices leaving possibly 170-190 entries for network
node definitions. NJE also had characteristic if that either the
origin or the destination nodes weren't in the local table, it trashed
the traffic. Even before NJE shipped to customers, the internal
network was over 255 nodes ... and you couldn't trust a NJE node to be
anything other than a pure edge node ... and not to be trusted as a
internal network backbone node (forwarded traffic between nodes).

eventually NJE did expand support to 999 nodes ... however that was
after the internal network had exceeded 1000 nodes (which met that
NJE still couldn't occupy a major backbone postition) ... minor
reference:
http://www.garlic.com/~lynn/internet.htm#22

to commemorate the 1000th node event there was a clear plexiglass
globe (about 3in diameter) with abstract representation of world
network and logo about 1000 nodes. It sat in a tripod formed by three
clear plexiglass rods (i've got one in my desk drawer).

NJE also had a shortcoming that it mixed up data attribute information
and network information in the header. With the intermingling of
header information ... NJE systems were notorious for bringing down
MVS when trying to handle NJE data that had originated from another
HASP/JES2 system that was running a different version ... and
incompatible header information.

One of the solutions was to create custom gateway drivers in the
primary networking implementation that compensated for NJE confusion
with handling data from other, incompatible NJE systems. Basically, it
became the responsibility of the gateway code to create canonical
representation of NJE header information ... and then a custom,
specific gateway driver would be started that corresponded to the NJE
version that it directly talked to. It was the responsibility of the
custom gateway driver to re-arrange the header bits to correspond to
the specific NJE version (as countermeasure preventing MVS system
crashes). Somewhere in this timeline there was an infamous incident of
JES2 systems in San Jose causing MVS systems in Hursley to crash.

In many ways the NJE architecture was similar to the original arpanet
design in that it was a homogeneous implementation (as were many other
network architectures from the 60s & 70s; and the arpanet was also
effectively limited to 255 nodes). The great conversion of
arpanet/internet on 1/1/83 to tcp/ip ... gave it gateway functionality
.. which it brought it more inline with the technolgoy of the main
core of the internal network.

misc. past posts mentioning NJE
http://www.garlic.com/~lynn/95.html#7 Who built the Internet? (was: Linux/AXP.. Reliable?)
http://www.garlic.com/~lynn/2001e.html#12 Blame it all on Microsoft
http://www.garlic.com/~lynn/2001g.html#48 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002b.html#53 Computer Naming Conventions
http://www.garlic.com/~lynn/2002h.html#2 DISK PL/I Program
http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
http://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002k.html#48 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002k.html#49 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002q.html#31 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2002q.html#35 HASP:
http://www.garlic.com/~lynn/2003.html#68 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003c.html#47 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003f.html#0 early vnet & exploit
http://www.garlic.com/~lynn/2003g.html#51 vnet 1000th node anniversary 6/10
http://www.garlic.com/~lynn/2003i.html#32 A Dark Day
http://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
http://www.garlic.com/~lynn/2004b.html#53 origin of the UNIX dd command
http://www.garlic.com/~lynn/2004g.html#35 network history (repeat, google may have gotten confused?)
http://www.garlic.com/~lynn/2004g.html#39 spool
http://www.garlic.com/~lynn/2004h.html#2 Adventure game (was:PL/? History (was Hercules))
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004n.html#45 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#60 JES2 NJE setup
http://www.garlic.com/~lynn/2004o.html#61 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3

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

Effective micropayments

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Effective micropayments
Newsgroups: sci.crypt
Date: Sun, 18 Sep 2005 12:02:33 -0600

"Milan VXdgsvt" writes:

Let's imagine the following setup: Alice wants to send many messages to
Bob, but she's not connected directly to Bob. Instead she has to
transmit messages to Robert the Retransmitter, who sends them to Bob.
The trouble is, Robert wants money for this, and does not want to spend
too much computation power on this.

it is called the internet. Alice is an ISP client. Robert is the ISP.

it used to be that people did offline email ... they called their
local (electronic) postoffice, exchanged email and hung up. both the
telco and the network service provider charged by the minute connected
and (sometimes the service provider charged by bytes transmitted).

there use to be these boxes by livingston and they came up with this
thing called radius (I confess to long ago and far away being involved
in helping with some radius stuff on real livingston box for very
small startup).

radius evolved into an ietf standard for authentication. authorization,
and accounting. misc. collected past postings mentioning radius
http://www.garlic.com/~lynn/subpubkey.html#radius

my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

in the RFCs listed by section, click on Term (term->RFC#)

and either click on "RADIUS" in the Acronym fastpath or scroll
down to

remote authentication dial in user service  (RADIUS )
 see also authentication , network access server , network services
 4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809
 2621 2620 2619 2618 2548 2139 2138 2059 2058

clicking on the rfc number brings up the rfc summary in the lower
frame. clicking on the ".txt=nnnn" field in the rfc summary, fetches
the actual RFC.

you might also be interest in some of the AAA working group

Authentication, Authorization and Accounting
 see also accounting , authentication , authorization
 3588 3539 3127 2989 2977 2906 2905 2904 2903

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

Article in Information week: Mainframe Programmers Wanted

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Article in Information week: Mainframe Programmers Wanted
Newsgroups: bit.listserv.ibm-main
Date: Mon, 19 Sep 2005 13:09:21 -0600

WM wrote:

I think you're on the right track, John. I've got a kind of
half-developed theory that staff that grew up in the mainframe era,
where computing resources were extremely expensive and data centers
were, actually, awesome, take their work very seriously.

Conversely, staff that learned on small Intel or Unix systems that were
easily available and may have just been in their basement, of course,
never had the concept that this is serious stuff requiring an
engineering approach. The stakes were lower. And of course with
develoment tools beyond 3GL languages, the effort to get *something*
programmed is much lower. Less entry barrier for writing simple
applications. Think MS Access here.

I've often voiced a different perspective on the subject. many of the
mainframes grew up with a batch paradigm ... which implied that the
responsible person wasn't around when the program was being run
... and therefor a huge amount of hueristics grew up over the years
about the system taking care of the stuff itself. Correllary is that
the huge body of stuff for system operational characteristics
eventually has created a steeper learning curve for people wanting to
do industrial strength dataprocessing.

The alternative are the systems evolving from the interactive, desktop
paradigm ... which assume that the responsible person is right there
and the system can always rely on a human for resolution rather than
having it figured all out by the system.

So almost all servers these days (even in the internet world) tend to
have industrial strength dataprocessing requirements ... even when the
server clients are of the desktop variety. The batch paradigm with the
system having resolution responsible also applies to many of the
online environments (as opposed to the strictly interactive kind)
... for instance large ATM cash machine network ... when there is a
problem, doesn't really want the customer out at an ATM machine,
exercising administrative type operations on the core authentication
& authorization engine.

part of the issue in large server infrastructures ... is that while
the actual $$/mip has drastically decreased ... the aggregate value
involved when there is a glitch in a large online system might be
enormous (because of possibly involving an impact for thousands of
people).

... various past postings regarding batch paradigm platfroms vis-a-vis
interactive paradigm platforms
http://www.garlic.com/~lynn/98.html#18 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/98.html#51 Mainframes suck? (was Re: Possibly OT: Disney Computing)
http://www.garlic.com/~lynn/99.html#16 Old Computers
http://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
http://www.garlic.com/~lynn/2004.html#43 [Fwd: Re: Mainframe not a good architecture for interactive w
http://www.garlic.com/~lynn/2004b.html#10 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004c.html#28 Moribund TSO/E
http://www.garlic.com/~lynn/2004o.html#21 Integer types for 128-bit addressing

.... this is a test ... my recent newsgroup postings have been
forwarded to the mailing list processor ... but are being bounced
(even tho I'm otherwise authorized) ... will see if this direct
mailing works.

a few of the recent bit.listserv.ibm-main postings ... a couple may
have been manually handled for the mailing list:
http://www.garlic.com/~lynn/2005o.html#45 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005o.html#47 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005p.html#0 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005p.html#13 One more about SYRES Sharing
http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#16 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS
http://www.garlic.com/~lynn/2005p.html#18 address space
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2005p.html#20 address space
http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
http://www.garlic.com/~lynn/2005p.html#34 What is CRJE
http://www.garlic.com/~lynn/2005p.html#37 CRJE and CRBE
http://www.garlic.com/~lynn/2005p.html#38 storage key question
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3

winscape?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers
Date: Tue, 20 Sep 2005 09:36:23 -0600

Andrew Swallow writes:

That takes 30 years.  20 more to go.

Force the graphic designers to demonstrate their webpages on PDAs.
They will learn quickly.

the internal net had been larger than the arpanet/internet from
just about the beginning until approx. summer '85
http://www.garlic.com/~lynn/subnetwork.html#internalnet

recent posting on some aspects of internal network
http://www.garlic.com/~lynn/2005q.html#0

i've frequently asserted that a major reason (internal network was
larger than the arpanet/internet) was that the internal network had
gateway-like technology in every node from just about the beginning
... which the internet/arpanet didn't get until the great switch-over
on 1/1/83
http://www.garlic.com/~lynn/rfcietf.htm#history

a major change-over to the internet was the actual deployment of major
production backbone ... not just having the technology for major
backbone.  nsfnet backbone rfp announcement.
http://www.garlic.com/~lynn/2002k.html#12

we weren't allowed to bid on the rfp
http://www.garlic.com/~lynn/2000e.html#10

however, we did get a technology audit by nsf ... which resulted in
something that claimed what we had operational was at least five years
ahead of all bid submissions to build something new ... although some
of the technology appears to more likely appear in internet2, closer
to 20 years later:
http://www.garlic.com/~lynn/internet.htm#0

we were asked to consult with this small client/server company over
ten years ago ... that wanted to do payment transactions on their
server ... they had this technology called ssl ... and has since
grown into this stuff frequently called e-commerce:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

note that some of the other technology was an outgrowth of
of some work at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

invented over 35 years ago
http://www.garlic.com/~lynn/submain.html#sgml

references tracing html to sgml & waterloo script (and thus back
to gml)
http://www.garlic.com/~lynn/2002b.html#46 ... the need for a Meseum of Computer Software
http://www.garlic.com/~lynn/2004l.html#72 Specificying all biz rules in relational data
http://www.garlic.com/~lynn/2005e.html#34 Thou shalt have no other gods befreo the ANSI C standards
http://www.garlic.com/~lynn/2005f.html#49 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005k.html#58 Book on computer architecture for beginners
http://www.garlic.com/~lynn/2005l.html#10 who invented CONFIG/SYS?

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

winscape?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers
Date: Tue, 20 Sep 2005 09:46:29 -0600

greymaus writes:

Ordering air tickets last night, finally got to the <credit> stage,
one had to click on a box to show you had read the conditions [usual
stuff], clicked on conditions highlite, box appeared, nothing in it, I
tried this in Firefox, Opera, Netscape, Konqueror, then changed to XP,
Opera, IE. I was so mad at this point at the thought that I would have
to use a M$ product, that I was relieved when nothing appeared under
IE, either. IE, however, sent me on to some M$ site when I mistyped
the name. Finally I just clicked on the [Have you read the conditions]
radiothingie, and things proceeded.  Odd legal point there, if there
is a dispute later.

a recent post on misunderstanding digital signature and human
signature ... possibly because of semantic confusion because
both terms contain the word signature.
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges

misc. collected posts on human & "e" signatures
http://www.garlic.com/~lynn/subpubkey.html#signature

we had been brought in to help word-smith cal. & then fed. electronic
signature legislation, misc. past posts mentioning electronic
signature (something that presumably carries the implication and
intent of human signature with matter having been read, understood,
agreed, approved, and/or authorized):
http://www.garlic.com/~lynn/aadsm3.htm#cstech cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech2 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aepay7.htm#etsi fyi ... Comments requested on ETSI Draft TR "XML format for signature policies"
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aepay10.htm#2 German federal employees get digital signatures
http://www.garlic.com/~lynn/aepay10.htm#7 UNCITRAL Electronic Contracting Project
http://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting)
http://www.garlic.com/~lynn/aepay10.htm#71 Invisible Ink, E-signatures slow to broadly catch on
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
http://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
http://www.garlic.com/~lynn/aadsm14.htm#19 Payments as an answer to spam (addenda)
http://www.garlic.com/~lynn/aadsm14.htm#43 PKI "not working"
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#39 FAQ: e-Signatures and Payments
http://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card
http://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2001g.html#25 Root certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2002e.html#18 Opinion  on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#1 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 20 Sep 2005 12:15:44 -0600

Rick Troth writes:

Very confusing page there.
Is it Itanium or MIPS?   Is it POSIX or the prior Tandem "Non-Stop OS"?

thread originally started in alt.folklore.computers newsgroup ...
where thread topics frequently drift far and wide ... i cross-posting
into bit.listserv.vmesa-l when there was some drift into vm area.

two x-posts
http://www.garlic.com/~lynn/2005p.html#26 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?

for instance, one of the primary people behind original relational/sql
http://www.garlic.com/~lynn/submain.html#systemr

wrote a departing note when he left sjr to go to tandem
http://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns

there was also something called tandem memos which i got blamed
for. basically an early computer conferencing activity (predating
toolsrun and listserv). as it became more visible ... there was even a
datamation article. sort of one of the eventual outcomes was that a
researcher spent 9 months in the back of my office ... taking notes on
all my communication. they also got logs of all my incoming and
outgoing email ... as well as logs of all instant messages. the study
eventually turned into a stanford phd thesis (joint between language
and computer ai) and material for subsequent papers and books
http://www.garlic.com/~lynn/subnetwork.html#cmc

some other posts in the original thread
http://www.garlic.com/~lynn/2005o.html#32 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005o.html#37 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#3 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#4 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#5 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#7 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#10 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#11 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#23 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#30 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#39 What ever happened to Tandem and NonStop OS ?

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

What are the latest topic in TCP/IP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What are the latest topic in TCP/IP.
Newsgroups: comp.protocols.tcp-ip
Date: Tue, 20 Sep 2005 12:39:57 -0600

"abrar_@yahoo.com" writes:

What are the latest topic in TCP/IP.
IS there any ongoing reserach in TCP/IP.Please identify for research
papares

try nsf & internet2 project with a search engine.

the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

was larger than the arpanet/internet from just about the beginning
until possibly mid-85. i've periodically claimed that a reason was
that the major internal network technology had a kind of gateway
capability in every node ... from essentially the start (effectively
eased the effort of heterogeneous networking) ... something that
arpanet/internet didn't get until the great change over on 1/1/83.
some historical references:
http://www.garlic.com/~lynn/rfcietf.htm#history

of course the other big transition was not only having the technology
deployed ... but also having operational backbone that leveraged the
technology (aka sort of the start of the modern internet).
http://www.garlic.com/~lynn/2002k.html#12 NSFNET Program Announcement

we were operating a high-speed backbone, but weren't allowed to bid
on NSFNET ... although one of the conclusions of a technology audit
by NSF was what we had running was at least five years ahead of all
bid submissions
http://www.garlic.com/~lynn/2000e.html#10 NSFNET Award Announcement

so internet2 may have some stuff that we were running way back then.
slightly related post from today in a.f.c. newsgroup
http://www.garlic.com/~lynn/2005q.html#3

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

HASP/ASP JES/JES2/JES3

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Tue, 20 Sep 2005 14:30:00 -0600

Allan Scherr wrote:

The way Spooling was done on the pre-S/360 systems, to my  recollection,
was with a second computer.  The 1410 did I/O for the  7010, for
instance.  The 1401 was used to to card to tape and tape to  printer for
larger computers.  The first general multiprogramming  capabilities that
I recall were in some of the IBM special purpose  systems in the early
60's like the SABRE airline reservations system  or the so called
"defense calculator" project that kept track of  radar threats.  The
operating systems I used in the 50's (SOS, FMS,  IBYSYS) had no
multiprogramming.  IBSYS for the 7094 may have picked  up this
capability near the end of its life in the early 60's, but I  didn't use
it by then.   Anyone remember?

the univ. had a 709/ibsys with 1401 front-end program called mpio that
handled unitrecord<->tape front-end (card reader->tape,
tape->printer/punch).

one can imagine the tapes as a kind of spool ... being moved
back&forth between the tape drvies on the different computers.

as part of the transition to 360, the univ. got a 360/30 replacing the
1401 ... which ran mpio in 1401 emulation mode most of the time. my
first student programming job was to re-implement the 1401 mpio
program in 360. i got to design my own interrupt handlers, device
drivers, storage allocation, task manager, console interface,
etc. Basically my own 360 stand-alone monitor that simulated all the
1401 mpio functions (but running in 360 mode rather than 1401 hardware
emulation mode).

it eventually grew to about a box (2000) assembler statements, i
assembled under an os/360 pcp on the 360/30 and then used a bps
standalone loader to run the program. I eventually added conditional
statements to do a stand-alone version and a os/360 version ... using
job control, dcbs, open/close, etc. doing the os/360 version took
about 30 minutes longer to assembler under os/360 pcp (i think release
6) on the 360/30 ... and it was almost all expanding the dcb macros
... you could watch the lights on the front panel and they
significantly changed when it hit a dcb macro ... taking 5-6 minutes
elapsed time for each macro.

the 709 was then replaced with a 512kbyte 360/67 supposedly for
tss/360 ... and then quickly upgraded to 768kbyte. the 709 had been
doing fortran student jobs measured at approx. one/second ... going
tape to tape. bare-bones os/360 release 9.5 on the 360/67 was doing
student fortran jobs measured in minutes (instead of
jobs/second). adding HASP to the system dropped the elapsed time per
student fortran job to a little over 30 seconds elapsed. misc. past
posts mentioning hasp
http://www.garlic.com/~lynn/submain.html#hasp

I then started looking at system in detail and especially stage-II.
Initially as part of doing a rebuild of release 9.5 ... i did a
stage-I sysgen and then got the stage-ii punched deck of cards ... and
then had them interpreted (printed across the top). I started by
trying to re-arrange the sequence of stage-II execution in order to
optimally control both dataset placement and order of PDS member
placement as means of doing disk arm motion optimization. By os
release 11 sysgen ...  I was also able to perform the stage-II system
in the production jobstream (instead of requiring stand-alone time)
and the resulting production system was running reference student
fortran job stream at a little over 12seconds/job ... as opposed to
over 30seconds/job for an "out-of-the" box system built with standard
sysgen process (although both systems using hasp). note that six
months or so of PTFs could slow the 12secs/job down to possibly 20secs
per job ... as critical pds members were replaced and messed up
placement for optimized disk arm motion.

the student fortran job workload didn't actually get back to the 709
thruput until after waterloo's watfor was installed at the univ.

the 360/67 wasn't actually used for much tss/360 work. the univ. ibm
se did get some weekend stand-alone time for doing some tss/360
testing.  because tss/360 was taking so long ... the univ. started
looking at cp/67. the last week in jan68, three people from the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech
came out to the univ. and installed cp/67.

sometime that spring (before i had done much optimization/rewrite)
there was some work with doing simulated interactive script
representing the student fortran workload. basically the same script
was run for four tss/360 users and 30 cp67/cms users (on the same
hardware). the interactive response time with workload of four
simulated users was well over one second. The same workload script
with 30 cms users (on the same hardware) was well under one second
(aka cp67/cms had higher thruput and better response running 30
concurrent users ... than tss/360 with the same workload but only four
concurrent users).

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Tue, 20 Sep 2005 14:53:26 -0600

Andrew Swallow writes:

Go back to IBM before they unbundled their systems software.

6/23/69 was the unbundling announcement ... and start of charging
for application software.

kernel/system software was still "free" under the theory that it was
required for the operation of the hardware.

my resource manager was selected to be the guinea pig for charging for
kernel software. i got to spend some amount of time over extended
period with the business and pricing people. the initial take was that
kernel software, not directly connected to hardware support could be
priced ... the resource manager improved system performance but wasn't
actually required for hardware operations (things like device drivers,
etc). misc. posts on paging, fair share scheduling, resource manager,
etc
http://www.garlic.com/~lynn/subtopic.html#wsclock
http://www.garlic.com/~lynn/subtopic.html#fairshare

some related posts on benchmarking and preparing the resource manager
for release
http://www.garlic.com/~lynn/submain.html#bench

when they decided to ship multiprocessing kernel support in the
release following ... there was a problem. I had included a bunch of
stuff in the resource manager that was required for multiprocessing
support. the licensing rules prevented charging for multiprocessing
support (since it was required to make multiprocessing hardware work)
... so therefor it was also against the rules to have a priced prereq.
for enabling multiprocessor support.

the eventual resolution was to move all the multiprocessor required
pieces out of the resource manager into the base (free) system.

misc. past postings about multiprocessing support
http://www.garlic.com/~lynn/subtopic.html#smp

misc. past posts about unbundling
http://www.garlic.com/~lynn/submain.html#unbundle

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Tue, 20 Sep 2005 15:38:50 -0600

"Jack Peacock" writes:

PC's got ethernet as soon as it was affordable, but before ethernet NICs
dropped in price PCs were still being connected locally, using ARCnet or
less often Token Ring.  Now it might have been only about 30% the thruput of
ethernet, but ARCnet worked quite well for slower micros in small networks.
Netware ran just fine over ARCnet.

I've never seen modems used for local interconnects.  For one thing, it's
much easier to run the serial directly, rather than use some kind of
telephone line.

As far as an internet connection, the modem was the limitation no matter
what was used, PC or workstation.  Or maybe I missed seeing the giant yellow
ethernet cable that ran across the country?  That fast 10mbit WS connection
to the server still had to squeeze through the 1200 baud modem to get
outside the computer center.

there was pcnet ... had cables about as thick as original e-net cables
and operation was more like cable tv head-end (and 1mbit/sec).

disk division had a prototype project called DataHub that started in
'81 that used pcnet. they had some amount of work-for-hire using some
(students, grad. students, ??) programmers in provo (in the thick of
it, one of the gpd people was traveling between san jose and provo
approx. once a week).

the project was eventually canceled ... and the group in provo were
allowed to keep the technology that they had worked on under the
work-for-hire contract. some folklore is that spawned a pc network
server company hdqt'ed in provo.

misc. past posts mentioning DataHub
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/2000g.html#40 No more innovation?  Get serious
http://www.garlic.com/~lynn/2002f.html#19 When will IBM buy Sun?
http://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
http://www.garlic.com/~lynn/2003e.html#26 MP cost effectiveness
http://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
http://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small  clusters
http://www.garlic.com/~lynn/2005p.html#23 What ever happened to Tandem and NonStop OS ?

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

Tapes (3590) and VM

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tapes (3590) and VM
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 20 Sep 2005 21:51:42 -0600

"Austin, Alyce" writes:

Is it really necessary to shutdown Linux before doing a DDR?  I did
a DDR and it seem to complete successfully without shutting down
Linux.  (At least, I didn't get any errors.)

DDR does a physical sequential dump. between the time the dump starts
and the dump ends ... linux could have updated the device in an
inconsistant sequence ... say a file that was non-consecutive, some at
the front of the device (already backed up) and some at the end of the
device (not already backed up).

the situation is further exhaserbated by unix paradigm that tends to
keep lots of stuff cached in memory and cached records not necessarily
written to disk in consistent member during normal operations.

real time backups of running systems have been done by:

1) sync a complete mirrored backup and then break the mirrored backup
at an integrated instant. this works when the operational system has
either been sync'ed in conjunction with breaking the mirrow ... or has
a consistent log.

2) operational system has a journal of all changes. the backup notes
the position of the journal at the moment the backup starts ...  and
then the position of the journal at the moment the backup ends and
appends that area of the journal. restore does the standard image
stuff ... and then replays the appended journal.

the amount/degree of the incronsistency can depend on how much
activity is going on in the production system while the backup is
running.

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

Securing Private Key

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing Private Key
Newsgroups: sci.crypt
Date: Wed, 21 Sep 2005 08:33:05 -0600

"Shakeel" writes:

My application make transactions in the database. To make transactions
secure or in other words only application can make transactions in DB
and not even the DB admin can. For that the application make digital
signature with each transaction. Now the problem is for digital
signature the key is needed, Hot to secure or manage that key.

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

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

private key operation is nominal handled as something you have
authentication ... aka the validation of a digital signature by a
public key implies that the originator has access to and use of the
corresponding private key.

integrity of the operation then comes down to providing for the unique
possession and use of that private key.

software based infrastructure tends to revolve around an encrypted
file "container" ... where there is an attempt at software eimulation
of a physical container. this typically starts with making the file
encrypted and various software flavors that request decryption key for
access & use of the private key. a widely used example is SSH ...
http://www.openssh.com
http://www.ssh.com

somewhat more secure is replacing the software/file container with a
real physical container ... hardware token with embedded chip.  there
are a number of them with various combination of integrity
characteristics. features can be

1) key pair generated inside the chip, public key exported, but the
private key is never divulged.

2) degree of tamper resistance, difficulty of physical attack on token
to extract private key

3) whether chip requires pin/password and/or biometric for correct
operation (multi-factor authentication)

physical tokens tend to have the added (integrity) characteristic that
the owner will realize when the token is lost/stolen and notify the
responsible parties to disable the corresponding public key. there was
a recent thread on the this subject about administrative
infrastructure for management of public keys in DBMS environments ...
using DBMS/RADIUS operation for key registration & administrative
validity.

misc posts related to aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Wed, 21 Sep 2005 13:05:25 -0600

echomko_at_@polaris.umuc.edu (Eric Chomko) writes:

Didn't IBM have a anti-trust suit started against them back in 1969?
Didn't get lifted until after the PC in 1981, ISA, etc.?

i wasn't involved in much of the details ... i have vague recollection
of somebody claiming that the holiday inn (corner of 101 & 17) was
filled with lawyers for over a year working on the case; also that
it was the lawyers that were one of the reasons for the relatively
fast uptake of gml (ancester of sgml, html, xml, et al) invented
in 1969
http://www.garlic.com/~lynn/submain.html#sgml

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

besides unbundling announcement on 6/23/69
http://www.garlic.com/~lynn/submain.html#unbundle

sbc was also divested. when the vm370 development group outgrew the
3rd floor (after having taken over the boston programming center
located on the 3rd floor), they moved out to the old sbc bldg. in
burlington mall.

I've related before I was told concerning some testimony at
the trial
http://www.garlic.com/~lynn/94.html#44 bloat
http://www.garlic.com/~lynn/96.html#20 1401 series emulations still running?
http://www.garlic.com/~lynn/99.html#231 Why couldn't others compete against IBM?
http://www.garlic.com/~lynn/2002c.html#0 Did Intel Bite Off More Than It Can Chew
http://www.garlic.com/~lynn/2003.html#71 Card Columns

I had also picked this story/ref.( looking for reference to another
cp67 system located in tech sq. other than science center) ... quote
goes into some detail about many aspects of the litigation
http://www.garlic.com/~lynn/2004l.html#19 Looking for Disk Calc program/Exec

from quicky search engine use
http://www.hagley.lib.de.us/1980.htm IBM antitrust suit records 1950-1982
http://www.hagley.lib.de.us/1912.htm IBM antitrust suit records 1969-1980

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

IPSEC with non-domain Server

From: lynn@garlic.com
Newsgroups: microsoft.public.security
Subject: Re: IPSEC with non-domain Server
Date: Thu, 22 Sep 2005 14:41:35 -0700

Steven L Umbach wrote:

If you are using ipsec for just "filtering" then no computer
authentication is used anyhow. If you are using it for AH/ESP to
authenticate computers and protect traffic integrity and
confidentiality then you need to use a computer authentication
method. Certificates is the most secure method and any Windows
2000/2003 Server can be a Certificate Authority though trusting your
CA may be an issue depending on whether or not you have access to
configure those computers that should be allowed access or distribute
them the CA's certificate. The problem with pre-shared key is that it
is stored on the computers that use it in clear text in the registry
and is could be easily recoverable [see link below]. If you do not
think that is a problem in your situation then it could be a viable
solution and not being in an AD domain is a plus for its use. If you
do use be sure to use a complex pre-shared key and change it on a
regular basis. --- Steve

http://online.securityfocus.com/infocus/1528
Attacks on IPSec and Other Security Concerns

There are some important security considerations to keep in mind about
IPSec in Windows:

a.. preshared keys are stored clear text in the registry, accessible by
administrators
b.. Active Directory stores IPSec configuration policies, and preshared
keys in the clear,

The original pk-init draft for kerberos had public keys registered in
lieu of passwords ...
http://www.garlic.com/~lynn/subpubkey.html#kerberos

with kerberos performing digital signature validation using the on-file
public keys for something you have authentication.

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

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

digital signature verification is typically a form of something you
have authentication, aka the originator has access and use of the
corresponding private key.

basically the core technology is asymmetric key cryptography ... what
one key encodes, the other key decodes (to differentiate from
symmetric key cryptography where the same key is used for both
encrypting and decrypting)

there is a business process defined called public key ... where one of
the key-pair is identified as public and freely distributed; the other
of the key pair is identified as private, kept confidential and never
divulged. The business process of maintaining unique access and use of
the private key is the basis for claiming something you have
authentication.

there is a business process defined called digital siganture ... where
the originator creates a digital signature by calculating the hash of
some message/document and then encodes the hash with the private key.
The recipient (relying party) recalculates the hash of the
message/document, decodes the digital signature with the corresponding
public key and compares the two hashes. If they are the same, then the
recipient (relying party) can assume

1) the message/document has not been altered since the digital
signature

2) assume something you have authentication; i.e. the originator had
access to and use of the corresponding private key.

Basically recipients and/or relying parties typically create a trusted
repository of known public keys (sometimes this has been referred to as
pre-shared keys). It is these on-file public keys, that recipients can
use for validating digital signatures.

Somewhat from the offline email days, there was a business process
defined that involves PKIs, certification authorities and digital
certificates. This was to address first time communication between
strangers where the parties have no prior knowledge and/or access to
any information source about each other (i.e. the "letters of credit"
model from sailing ship days). The scenario was that the recipient
dialed their local (electronic) post office, exchanged email, hungup
and potentially faced dealing with first time email from total
stranger and had no facilities for obtaining information about the
stranger.

In this scenario, the total stranger has gone to a certification
authority, registered their public key, and claimed some information
about themselves. The certification authority verifies the claimed
information and issues a digital certificate attesting to the
certification of the public key and the claimed information. The
stranger now can create a message, digitally sign the message, and
transmit the a) message, b) digital signature and c) digital
certificate.

The recipient has (hopefully) preloaded their trusted public key
repository with the public keys of some number of certification
authorities. Now instead of directly retrieving the stranger's (on
file)public key from their repository to validate the digital
signature on the message ... they retrieve the on-file public key of
the certification authority to validate the digital signature on the
digital certificate. If that digital signature correctly validates,
then they use the stranger's public key from the digital certificate
to validate the digital signature on the actual message. This is the
use of pre-shared, on-file public keys (of certification authorities)
for one level indirection to handle the case of validation digital
signatures in first time communication with strangers.

PKI and digital certificate support was added to the pk-init draft for
kerberos so that the authentication of total strangers would be
enabled for system access.

The other widely deployed authentication mechanism is RADIUS ... which
also originated in the same time-frame as kerberos and also originally
followed a userid/password model. Definitions for RADIUS operation
have also been made where public keys can be registered in lieu of
passwords and digital signature validation cane be done with the
pre-shared, on-file public keys for something you have
authentication
http://www.garlic.com/~lynn/subpubkey.html#radius

In the early 90s, there was some direction by certification
authorities to create additional value population for x.509 identity
certificates to increase the amount of personal information. Part of
this was based on the fact that certification authorities might not
know at certification time all the possibly relying parties that might
be using the certificates in the future ... and therefor might not
know ahead of time what was all the personal information that a
relying party might need to know about an individual.

By the mid-90s, some number of institutions were starting to realize
that x.509 identity certificates grossly overloaded with enormous
amounts of personal information represented significant privacy and
liability issues. The other issue was the addition of x.509 identity
certificates on every operation, turned even the most trivial
authentication operation into a heavy-weight identification event.
Recent posts on subject of confusing identification and authentication
http://www.garlic.com/~lynn/aadsm20.htm#42
http://www.garlic.com/~lynn/aadsm21.htm#2
http://www.garlic.com/~lynn/aadsm21.htm#12

In response there was the creation of relying-party-only digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

which were basically limited to the public key and some sort of
repository/database lookup index or account number (where all the real
information about the individual was kept). However, it is trivial to
demonstrate that if the relying party has all the information
(included the pre-shared, pre-registered public key) then the any
appending of a digital certificate to an authentication operation is
total redundant and superfluous.

A digital signature will be appended to a basic transaction containing
some sort of index. The relying party, pulling that record gets all
the necessary information about the signing party, including their
pre-shared, on-file public key (that can be used for validating the
digital signature).
http://www.garlic.com/~lynn/subpubkey.html#certless

one of the basic reasons for upgrading password-based infrastructure
(kerberso, radius, etc) to (pre-shared, on-file) public keys is that
passwords are shared-secret infrastructures
http://www.garlic.com/~lynn/subintegrity.html#secret

akin to symmetrical key ... where the same value is used for both
origination and authentication. being able to access the value (for
authentication or other purposes) potentially exposes the value to
leakage and use for impersonation ... where public keys are only used
for authentication.

from the security PAIN acronym

• privacy
• authentication
• integrity
• non-repudiation

a shared-secret will have both privacy and integrity requirements
(although having regular access for authentication purposes can
compromise the privacy constraint). a public key basically only has
integrity requirements (by definition, it doesn't have to be kept
private and never disclosed).

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Thu, 22 Sep 2005 18:21:25 -0600

"Rupert Pigott" writes:

OSF/1 was renamed Digital Unix, which in turn was renamed
to Tru64 (a typically tacky touch from Compaq). I mostly
used it when they called it Digital Unix. I saw more DU
boxes out there than VMS boxes in the mid-late 90s.

OSF/1 (aka Digital UNIX, aka Tru64) was SVR4 style. AFAIK
ULTRIX started as 4.2 BSD, some antique application source
suggested that too.

OSF was open systems foundation; HP, IBM, DEC, etc ... countermeasure
to ATT/SUN integrating SVR4. It was going to have equivalent function
to SVR4 ... but hopefully allowed the other players to have some
options if ATT/SUN took any adverse action in the interest of
competitive protection.

It also had DCE ... distributed computing environment; tried to merge
(at least) Apollo domain stuff, IBM AIX DFS (distributed file system),
CMU AFS and UCLA's LOCUS distributed stuff.

As an aside, the "risc" AIX (romp/aixV2 & rios/aixV3) had started
out ATT derivative (aka the company that had done the AT&T port
for IBM's PC/IX for the ibm/pc was hired to do one for romp/aixV2)
http://www.garlic.com/~lynn/subtopic.html#801

... while the AIX/370/PS2 had started out UCLA Locus

I remember seeing some DEC people at OSF meetings that had been with
IBM on cp67/vm370 ... and were some of the people that left IBM when
the vm370 development group was shutdown (in burlington mall) and
everybody was told that they had to move to POK (to help support
mvs/xa development).

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

HASP/ASP JES/JES2/JES3

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Date: Thu, 22 Sep 2005 18:07:25 -0600
Newsgroups: bit.listserv.ibm-main

Skip Robinson wrote:

My favorite is still ISPF. It's predecessor, SPF, expressly stood
for Structured Programming Facility. Not content merely to add
Interactive, the Hot Button Brigade (tech savvy cousins of the
Political Correctness Police) also re-engineered 'SP' to System
Productivity.

there is GML (precursor to sgml, html, xml, etc) .... which was
invented at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

in 1969 by three people, "G", "M", and "L". it then became a task to
come up with "generalized markup language" to correspond with the
initials of the three last names

http://www.garlic.com/~lynn/submain.html#sgml

then there is CAS ... the initials for the person at the science
center that was doing a lot of fine-grain SMP locking work on cp/67
and invented a new multiprocessing syncronization instruction.

It was then necessary to come up with compare&swap to go along
with his initials.  trying to get CAS into 370 architecture ... the
370 architecture group in POK said that it wasn't possible to justify
an multiprocessing-specific instruction for 370 so it would be
necessary to invent a use for the instruction in non-multiprocessing
environment ...  thus was born the programming notes on how to use CAS
by multi-threaded applications (whether they were running on
uniprocessor or multiprocessor). Also in getting CAS into 370 ... both
a word and double word version were defined so the mnemonic got changed
from CAS to CS and CDS (it was going to be the only mnemonic that i
know of that started out as somebody's initials)
http://www.garlic.com/~lynn/subtopic.html#smp

and then of course there is SCIDS
http://www.garlic.com/~lynn/2000d.html#5 Definition of SHARE & SCIDS Requested
http://www.garlic.com/~lynn/2000d.html#6 Definition of SHARE & SCIDS Requested

HASP/ASP JES/JES2/JES3

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Date: Thu, 22 Sep 2005 18:32:44 -0600
Newsgroups: bit.listserv.ibm-main

and of course in the interest of political correctness when cp67
morphed into vm370 .... the cambridge monitor system (cms) was reborn
as the conversational monitor system.

Ethernet, Aloha and CSMA/CD -

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet, Aloha and CSMA/CD -
Newsgroups: comp.arch.embedded,alt.folklore.computers
Date: Fri, 23 Sep 2005 10:06:11 -0600

Roberto Waltman writes:

May be, but it also may have been an unavoidable mistake - I can not
think of a better approach for Hawaii's original ALOHA radio network
on which Ethernet/CSMA/CD where partially based. (Especially when
you consider the technology available at the time.)

Each station in the Aloha network could not listen to the others,
both because of the terrain of the island and because the antennas
were directed to the "common medium", the satellite, so they had to
broadcast blindly and wait for the satellite to echo it back to all
the stations + acknowledge, as an indication that there was not
collision.

one of the things we did in the hsdt
http://www.garlic.com/~lynn/subnetwork.html#hsdt

in the 80s was design and deploy tdma earth stations ... we got a
transponder on sbs-4 ... and even got to go to the launch party
at the cape (complicated by the scrubs):
http://www.nasa.gov/mission_pages/shuttle/shuttlemissions/archives/sts-41D.html

slightly related post (at the very bottom mentioning AT&T)
http://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits

we were getting into some fancy dynamic bandwidth re-allocation on
superframe boundary. the stations were also capable of agile frequency
hopping.

a little topic drift ... may wife is listed as co-author on
early token-passing patent
http://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
http://www.garlic.com/~lynn/2005i.html#43 Development as Configuration

there is even a tie-in between the rios chip design work going on
in austin and the lsm & eve out in the valley
http://www.garlic.com/~lynn/subtopic.html#801

for even more drift:
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns

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

Ethernet, Aloha and CSMA/CD -

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet, Aloha and CSMA/CD -
Newsgroups: comp.arch.embedded,alt.folklore.computers
Date: Fri, 23 Sep 2005 10:30:43 -0600

"Tim Shoppa" writes:

The token ring advocates always pointed out how certain circumstances
could lead to collision detection not working nicely.  They were also
extremely unconfortable with the lack of guaranteed bandwidth for each
master etc.

But the token ring vs collision detection wars for general-purpose
networking were fought and token ring lost.  In real life the concerns
that the token ring advocates had about collisions just don't happen,
even on highly saturated ethernets.

the big transition for ethernet was adding listen before transmit (and
adapting t/r cat5 hub/spoke)

my vague recollection was early ethernet was 3mbit/sec, didn't do
listen before transmit and had this big thick cables ... looked a lot
like the pcnet cables (which i believe did 1mbit/sec but used a tv
head-end type implementation).

when we had come up with 3-tier architecture and were out pitching
in in executive presentations
http://www.garlic.com/~lynn/subnetwork.html#3tier

we were getting a lot of push-back from the saa and token-ring folks.
some characterized the saa effort as trying to put the client/server
genie back into the bottle ... aka maintain the terminal emulation
operation
http://www.garlic.com/~lynn/subnetwork.html#emulation

and since we were pitching enet ... the token-ring people were also
getting really upset. some t/r person from the dallas engineering &
science center had done a report that showed enet typically only got
1mbyte/sec thruput (we conjectured that they based the numbers on old
3mbit/sec implementation before listen before transmit).

research had done a new bldg. up on the hill ... and it was completely
wired with cat5 supposedly for t/r ... but they found that they were
getting higher thruput and lower latency using it for star-wired
10mbit ethernet (even compared to 16mbit t/r). adapting the t/r
hub&spoke cat5 configurations to ethernet tended to reduce the worst
case latency on listen before transmit. this improved further by
making the hub active ... so worst case was longest leg to the hub
rather than latency across the hub between two longest legs.

then a paper came out in 88 acm sigcomm showing that a typical 10mbit
ethernet star-wired hub configuration with all stations doing worst
case, low-level device driver loop transmitting minimum sized packets
was getting aggregate effective thruput of 85 percent of media
capacity.

misc. past refs:
http://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
http://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2000f.html#39 Ethernet efficiency (was Re: Ms employees begging for food)
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002.html#38 Buffer overflow
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#9 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2002q.html#41 ibm time machine in new york times?
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2003k.html#57 Window field in TCP header goes small
http://www.garlic.com/~lynn/2003p.html#13 packetloss bad for sliding window protocol ?
http://www.garlic.com/~lynn/2004e.html#13 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004e.html#17 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
http://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
http://www.garlic.com/~lynn/2005i.html#43 Development as Configuration

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

HASP/ASP JES/JES2/JES3

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Newsgroups: bit.listserv.ibm-main
Date: Fri, 23 Sep 2005 10:56:10 -0600

JO.Skip.Robinson@ibm-main.lst wrote:

At the opposite extreme we have TSO, which as far as I know still stands
for 'Time Sharing Option' but has not shared time or been optional for
decades. I guess that's how you know when you're no longer strategic:
nobody bothers to rebirth your obsolete acronym.  ;-(

VSPC was originally going to be called PCO (somewhat patterned after
TSO) ... personal computing option ... however, somebody pointed out
that there was a relatively well-known organization in France that
went by PCO ... resulting in the name change to VSPC.

recent posting ref.
http://www.garlic.com/~lynn/2005p.html#38 storage key question

Ethernet, Aloha and CSMA/CD -

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet, Aloha and CSMA/CD -
Newsgroups: comp.arch.embedded,alt.folklore.computers
Date: Fri, 23 Sep 2005 13:10:07 -0600

ref:
http://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD
http://www.garlic.com/~lynn/2005q.html#18 Ethernet, Aloha and CSMA/CD

the whole saa & terminal emulation forever
http://www.garlic.com/~lynn/subnetwork.html#emulation

overflowed into a number of areas.

romp/pcrt
http://www.garlic.com/~lynn/subtopic.html#801

had done a customer 16bit 4mbit/sec t/r card ... and then the
group was mandated that they had to use the PS2 microchannel
16mbit/sec t/r card for RIOS/6000.

the problem was that the PS2 card had the SAA and terminal emulation
design point where configurations had 300 PCs per t/r lan; bridged,
sharing common theoritical 16mbit (but in acutally much less), no
routers, no gateways, etc. SNA didn't have a network layer ... just
table of physical mac addresses ... modulo when APPN was introduced.
We use to kid the person responsible for APPN that he should stop
wasting his time trying to further kludge up SNA (the SNA group had
non-concurred with even announcing APPN, there was a several week
escalation process and the APPN announcement letter was rewritten to
not imply any relationship between APPN and SNA).

In any case, the pc/rt & rios market segment was supposedly
high-performance workstations, client/server, and distributed
environment. The custom pcrt 16bit 4mbit/sec t/r card actually had
higher per card thruput than the PS2 32bit 16mbit/sec t/r card (again
the saa terminal emulation paradigm).

the pcrt/rios market segment required high per card thruput for high
performance workstations and servers (in client/server environments
where traffic is quite asymmetrical).

in this period, a new generation of hub/spoke enet cards were
appearing (with new generation of enet controller chips like the 16bit
amd lance), where each card was capable of sustaining full 10mbit (aka
a server could transmit 10mbit/secs serving a client base having
aggregate 10mbit/sec requirements).

by comparison, the microchannel 16mbit t/r environment actually had
lower aggregate thruput and longer latencies ... AND the available
cards had per card thruput designed to meet the terminal emulation
market requirements (and one could say that the lack of high thruput
per card also inhibited the evoluation of client/server ... as well as
the 3-tier middle layer/middleware paradigm that we were out pushing).

my wife had co-authored and presented a response to a gov. request for
high integrity and operational campus-like distributed environment ...
in which she had originally formulated a lot of the 3-tier principles.
http://www.garlic.com/~lynn/subnetwork.html#3tier

we then expanded on the concepts and were making 3-tier and middle
layer presentations at customer executive seminars ... heavly laced
with high-performance routers aggregating large number of enet
segments. instead of having 300 machines bridged, sharing single
16mbit t/r, you had 300 "clients" spread across ten or more enet
segments with high-speed router (aggregate sustained 200mbit/sec
-400mbit/sec thuput) ...  with servers having separate dedicated
connectivity to the high-speed routers. other components then were
used to stage and complete the 3-tier architecture. a couple of past
posts in answer to question on the origins of middleware
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer

this also contributed to the work that we did coming up with
the ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

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

Ethernet, Aloha and CSMA/CD -

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet, Aloha and CSMA/CD -
Newsgroups: comp.arch.embedded,alt.folklore.computers
Date: Fri, 23 Sep 2005 13:43:55 -0600

Anne & Lynn Wheeler writes:

in this period, a new generation of hub/spoke enet cards were
appearing (with new generation of enet controller chips like the
16bit amd lance), where each card was capable of sustaining full
10mbit (aka a server could transmit 10mbit/secs serving a client
base having aggregate 10mbit/sec requirements).

ref:
http://www.garlic.com/~lynn/2005q.html#20 Ethernet, Aloha and CSMA/CD

... and the street price of the new generation of 16bit enet cards
capable of sustaining 10mbit/sec/card was heading towards $49/card
... while the ps2 microchannel 16mbit t/r cards (where you were lucky
to get much more 1mbit/sec/card, aks the per card sustained thruput
was less than the pc/rt 16bit 4mbit/sec t/r card) were holding in at
over $900.

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

tcp-ip concept

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: tcp-ip concept
Newsgroups: comp.protocols.tcp-ip
Date: Sat, 24 Sep 2005 11:46:04 -0600

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

The two directions are not independant. TCP in one direction will
only send as much data as will fill the negotiated window size;
after that, it needs an ACK from the other end before it sends more.
That ACK is a "response". The ACK need not be accompanied by any
meaningful data, but it is still a response.

somewhere in one of the early tcp RFCs there is a discussion of
problems remapping TCP from host protocol to IP. the original tcp
implementation on arpanet/host protocol had independent transmission
and control flows. The problem with mapping TCP to IP ... was that the
data & control flow information was mapped into same stream.

that could mean that ACKs and data were mixed in the same (reverse)
stream with possible impact on (returning) ACKs.

in the 88 time-frame there was presentation at IETF meeting regarding
slow-start for various TCP uses ... where the number of outstanding
windows would be slowly opened up (number of packets sent before an
ack was required back). this was trying to trade off delay
compensation (large number of outstanding un-acked packets) and
congestion (large number of outstanding un-acked packets resulting in
packet loss).

at approx. same time, there was paper published in acm sigcomm
proceedings showing that slow-start was non-stable in real-world
conditions. part of the issue was that intermediate nodes could have
packet loss with multiple back-to-back packet arrival. returning flow
could bunch up ack responses ... resulting in multiple packets being
"opened" immediately ... and the resulting transmission of multiple
back-to-back packets.

during this period, i was doing a lot with dynamic adaptive rate-based
pacing as a mechanism to try and trade-off outstanding packets and
delay compensation against congestion. in this case, the outgoing
packet flow is regulated ... but it isn't dependent on returning
packet acks for the regulation mechanism (and it explicitly addresses
multiple back-to-back packets saturating an intermediate node as well
as processing latencies at the remote end).

part of this is that ACK originally somewhat was a protocol mechanism
to address processing latency at the remote end of point-to-point link
... where the link transmission was nearly instantaneous and the issue
was overruning the buffer processing at the remote end. the two ends
negotiated the number of available buffers ... unacked packets implied
buffers that were in-use ... acks implied buffers that had been
processed and freed. it was overrun control in a much more static
environment. large internet environment with 30-30 or more hops (and
each hop is an intermediate node that can be overrun) ... doesn't have
the reserved buffers of the original ACK design point.

however, TCP was originally intended as a full-duplex operaton ...
streams in each direction operating asynchronously ... and end-point
buffer overrun issues handled with independent control channel (for
ack protocols). Translation to IP resulted in merging the control and
data channels in the same transmission stream.

In the rate-based scenario ... I would sometimes further highlight the
asynchronous independence of the transmission streams in each direction
by referring to it as dual-simplex as opposed to full-duplex.

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

Logon with Digital Siganture (PKI/OCES - or what else they're called)

From: <lynn@garlic.com>
Newsgroups: microsoft.public.dotnet.languages.csharp
Subject: Re: Logon with Digital Siganture (PKI/OCES - or what else they're called)
Date: Sat, 24 Sep 2005 12:49:19 -0700

Martin Høst Normark wrote:

Hi everyone

Has anyone got the least experience in integrating the Digital Signature
with an ASP.NET[C#] Web Application?

Here in Denmark, as I supose in many other countries, they're
promoting the digital signature. A lot of people already has one, to
do their taxes, and much more. I have to use for a
business-to-business e-commerce solution, where it's vital that the
right user is being logged on, and not give his username and password
to a colleague...

Due to the Digital Signatures usage, companies are very aware of
which employees has access to tax, VAT and things like that - and I
can make a more secure web application...

Anyone with just a good idea, own experiences, good links, or
something?

One of the issues has been confusing identification and
authentication.

the basic technology is asymmetric key cryptography; what one key (of
a key-pair) encodes, the other key decodes (to differentiate from
symmetric key where the same key is used for encryption and
decryption).

there is business process defined called public key ... where one of
the key (of an asymmetric key pair) is defined as public and made
freely available and the other is identified as private and kept
confidential and never divulged.

there is a business process defined called digital signature ... where
the originator calculates the hash of a message/document and encodes
it with their private key resulting in something called a digital
signature. they then transmit the message/document along with the
digital signature. The recipient recalculates the hash on the received
message/document, decodes the digital signature with the
(corresponding) public key and compares the two hashes. If they are
equal, then the recipient can assume:

1) the message/document hasn't been modified since signing
2) something you have authentication, i.e. the originator had
access to and use of the private key.

Basically, recipients build up a trusted repository of public keys
used for verifying digital signatures.

Digital signatures have also been used to upgrade existing
shared-secret
http://www.garlic.com/~lynn/subintegrity.html#secret

where the public key is registered in lieu of a pin/password and
instead of matching pin/password, the public key is used to verify the
originator's digital signature.

the most world-wide pervasive authentication infrastructure is
possibly RADIUS (extensively used by ISPs and other organizations for
integrated administrative authentication, authorization, and
accounting). This was originally been password based infrastructure
... but has been upgraded with other technologies, like registering
public keys in place of passwords ... and the method of authentication
can be selected on an account-by-account basis.
http://www.garlic.com/~lynn/subpubkey.html#radius

another widely deployed (originally password) authentication
infrastructure is KERBEROS ... originally developed as part of MIT's
project athean (my wife and I periodically did project athena
technology audits in the late 80s). You find KERBEROS integrated into
lots of distributed infrastructures like windows and most unix
flavors.  Originally, the internet draft for upgrading KERBEROS to
digital signature verification PK-INIT ... specified simply
registering public keys in lieu of passwords.

Another business process related to digital sigantures and public keys
that evolved involves certification authorities (CAs), digital
certificates, and PKIs. The paradigm is analogous to the "letters of
credit" (or letters of introduction) from the sailing ship days. The
design point is the offline email environment from the early 80s,
where the recipient dials-up their local (electronic) post office,
exchanges email, and hangs up. They then may be faced with first-time
communication from complete stranger ... with no local information
about the stranger and no resources available for obtaining
information about the stranger.

The idea is that there are these things called trusted certification
authorities that certify information about strangers and create
digitally signed digital certificates that contains the certified
information. Recipients (or relying parties) are expected to load the
public keys of certification authorities into their local trusted
public key repositories.

Now when a stranger signs a message/document, they can transmit the
message/document, their digital signature, and their digital
certificate. The recipient will (hopefully) have the public key of the
certification authority in their local trusted public key repository
... and can verify the CA's digital signature on the digital
certificate. From this, the recipient can supposedly trust the
information in the digital certificate. The recipient retrieves the
stranger's public key (that has also been included in the digital
certificate) and verifies the stranger's digital signature. The
recipient now supposedly can use information about the stranger
included in the digital certificate to determine what to do next.

One of the issues in the early 90s, was the x.509 identity certificate
standard ... that also included something called the non-repudiation
bit.

Basically certification authorities were looking at increasing the
value of digital certificates that they were selling. First they were
advocating that x.509 identity digital certificates be included on all
digitally signed authentication events .... turning even the most
simple and trivial authentication operation into a heavy duty
identification operation (and not just simply limited to first time
communication between strangers that had no other way of finding
information about the other party ... either offline or online).

The other issue is that the certification authorities didn't
necessarily know at the time they were creating an x.509 identity
certificate ... exactly what information that all possible recipients
might be interested in. As a result there was some direction to
include enormous amount of personal information in these x.509
certificates (grossly aggravating the scenario of turning even the
most trivial authentication operation into a heavy duty identification
operation).

Then there was the non-repudiation flag. This possibly was the
result of some semantic confustion where the term digital signature
 and the term human signature, both contain the word signature.
The non-repudiation flag in a digital certificate supposedly met
that the related digital signature effectively carried the weight of a
human signature ... i.e. human intent, read, understood, agrees,
approves, and/or authorizes what was digitally signed.  It
eventually became obvious that the setting of a flag in a digital
certificate by a certification authority possibly months in the past
.... could not actual guarantee that a human has read, understood,
agrees, approves, and/or authorizes something. As a result, the
non-repudiation flag has become severely depreciated.

The other gap in the PKI protocol with respect to non-repudiation flag
was that there is nothing in standard PKI protocols that can proove
what specific digital certificate a person actually attached to any
specific message. Given that a person might have two different digital
certificates for the same public key ... one with the non-repudiation
flag and one w/o the non-repudiation flag, then (in theory) the
recipient need only be able to find and produce the digital
certificate with the non-repudiation flag ... to demonstrate that what
had been digitally signed is bound by human signature and
non-repudiation rules.  Again, after some real world experience, it
quickly became evident that such a scenario was outlandish.

Going into the mid-90s, some number of institutions were starting to
realize that x.509 identity certificates, grossly overloaded with
enormous amounts of personal information, represented significant
privacy and liability issues. As a result, you started to see
something called relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

possibly the first ones that I'm aware of, were by a large german
financial institution.  The scenario is that the institution places
all the information about the individual in an accessable database and
the digital certificate is purely loaded with the index pointer to the
database entry and the individual's public key. In turns out that it
became trivial to proove that relying-party-only digital
certificates are redundant and superfluous; in part because it
violates the fundamental design point originally used to justify PKI
and digital certificates (the recipient had no other way of obtaining
information about the originating entity). Given that the recipient
(relying party) has to use the database index to access a database
entry, by definition they already have all the information that might
be represented by a digital certificate.

In such situations, it is trivial to eliminate the redundant and
superfluous digital certificates and return to the original digital
signature authentication design ... using the information that the
recipient already has access to.
http://www.garlic.com/~lynn/subpubkey.html#certless

note that sometime after the original pk-init draft for Kerberos, it
was updated to add the possibility of supporting PKI-based operations
(as opposed to simple, straight-forward registrations of public keys
in lieu of passwords) so that it would be possible for total strangers
to logon to your system (as per the original design point justifying
PKI, certification authorities, and digital certificates).

As an aside ... there is further problem with trying to use digital
signatures for both authentication as well as indication of human
signatures involving intent, read, understood, agrees, approves,
and/or authorizes. I've refered to this as a dual-use
attack/vulnerability.

Many of the digital signature authentication infrastructures involve
servers transmitting random data to the client for digital signing (as
a countermeasure to replay attacks). The client
digitally signs the random data (w/o ever having read, understood,
agrees, approves, and/or authorizes) and returns the digital
signature. The issue is that an attacker might include some valid
transaction or contract in lieu of random bits, the client then
applies a digital signature to the (not-so-)random bits ... and the
attacker then uses the information and digital signature as proof of a
valid transaction/contract.

some number of past collected posts on electronic signature
legislation (my wife and I were brought in to help word smith the
cal. electronic signature and then the fed. electronic signature
legislation), non-repudiation, and human intent ... as well as
some postings about identification and authentication being frequently
confused
http://www.garlic.com/~lynn/subpubkey.html#signature

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

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

here are a couple posts that reference two-factor
authentication involving a chipcard performing digital signature
(something you have authentication) and a PIN (something you
know authentication) ... where the entering of the PIN can also be
used as an indication of human signature. The scenario is that
the chipcard calculating a digital signature has none of the
characteristics required for establishing human intent, read,
understood, agrees, approves, and/or authorizes. However, a
certified terminal can display a message that says "enter your PIN if
you agree to the transaction". The physical hitting of keys in
response to a message can be used to establish human intent (in
addition to knowing the correct PIN being used as a form of
two-factor authentication). The interesting aspect is that it
is the entering of the PIN (human hitting keys in response to a
mesage) that is the basis for human signature (i.e. demonstration of
human intest, read, understood, agrees, approves, and/or
authorizes) and not the generation of a digital signature (where
possibly because the term digital signature and human
signature both contain the word signature that gives rise
to frequent confusion).
http://www.garlic.com/~lynn/aadsm21.htm#3 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges

some past posts on digital signature dual-use attack
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sat, 24 Sep 2005 16:02:04 -0600

jmfbahciv writes:

His dream had always been to make a new (and I mean new) OS.  He had
extensive experience in what not to do w.r.t. memory management,
interrupt handling, virtual memory, etc.  He knew the pluses and
minuses of TOPS-10, TOPS-20, VMS, and two flavors of Unix, one
intimately.  With all that OS background, turning him and a few
others loose on an R&D project would have been profitable and
useful.  When given the job of OS/1 (in the beginning) he somehow
got the impression that this new design was the goal.  It was not;
the design had to be Unixy.  I never understood putting that
constraint on the project.

i had the unfortunate delusion of attempting something similar in the
mid-80s; it was becoming more & more apparent that distributed
computing was going to take over the environment.

we previously had an effort to build the software for this new thing
coming out of boca called acorn. boca was claiming that they were
doing no software and they needed other organizations to do it ... we
dutifully checked with them monthly on the position vis-a-vis software
... and for some period they re-affirmed it. then, at one point ...
they decided they wanted to "own" software ... and internal operation
represented internal organization competition ... if we wouldn't move
to boca, they would contract for software outside (since external
contracts wouldn't carry with it the internal organization competition
issues).

in any case, it seemed that a portable, more sophisticated operating
system was needed (to compete with the emerging workstation unixes and
stuff starting to move upstream from the desktop). it was initially
defined to be a straight-forward, just do-it, with a small team.
Unfortunately it acquired some attention that it could represent a
significant corporate strategic direction. You had to be sure that
significant corporate strategic direction was done correctly ... so
eventually there was something like 300 people making sure the
specification was complete and correct ... and it eventually collapsed
from its own weight.

One observation was that there were technical alternative resolution
meetings (that frequently never arrived at any definitive conclusion,
but) that consumed far more resources than it would have taken to
actually implement all possible technical alternatives and do real
world comparisons to arrive at resolution. The corollary is that it
can be detrimental having too many smart people.

In some respects it was a mini-repeat of the FS fiasco from some ten
years earlier
http://www.garlic.com/~lynn/submain.html#futuresys

lots of different people had their favorite features that just had to
be part of any new OS. if this was going to be the one and only
operating system redo of the decade ... then each of these features
had to be included ... and eventually the effort collapsed from the
weight of the enormous number of requirements (if nothing else).

There was a little "I told you so" ... from the very first proposal
and at every subsequent opportunity ... I strongly asserted that the
effort wouldn't be succesful unless it was kept extremely small and
focused (KISS). Of course, I had also ridiculed the earlier FS effort
from the sidelines ... as the inmates taking over the asylum
(reference to the cult-film that had been playing non-stop in central
sq. during the FS days).

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sat, 24 Sep 2005 19:02:29 -0600

Jim Brooks writes:

My speculation is that Intel will build on their HyperThread experience
to design a "parallel x86".  x86 CPUs have become superscalar machines.
The next evolutionary step is a parallel machine.  Dual-cores are only
an inefficient stop-gap design that wastes transistors with duplicated
or unnecessary resources (eg coherency logic between the core's caches).

intel back to the future? old posting
http://www.garlic.com/~lynn/2001n.html#83 CM-5 Thinking Machines, Supercomputers

that includes pieces of some old news articles ... inclucing an NYT
article from 6/15/92 titled Foray into Mainstream for Parallel
Computing. some number of the efforts from the period were parallel
x86s ... also can anybody say Intel Paragon?

how 'bout ncube:
http://en.wikipedia.org/wiki/NCUBE

iPSC
http://www.cs.kuleuven.ac.be/museum/multiproc/myosotis-E.html

IPSC/2 hypercube
http://portal.acm.org/citation.cfm?id=255159

red asci, originally pentium pro, then updated to pentium II ..
http://en.wikipedia.org/wiki/Intel_ASCI_Red
http://www.sandia.gov/ASCI/Red/

in the mid-90s, there there were so many people tied up in working on
such stuff that one such new mpp project ... looking around for people
to lead the effort, got around to asking my wife and me.  I ran thru
all the names I could think of them to ask (before us) ... and they
pointed out that everybody I suggested, were all busy, tied up on
something else

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 25 Sep 2005 09:25:05 -0600

"Rupert Pigott" writes:

Amdahl released "UTS", a UNIX that ran under VM on their IBM
mainframe clones (they produced very big fast machines). Also
Cray shipped a UNIX called "UNICOS" with their supercomputers.

a couple recent UTS related post ... originally called gold (think
atomic symbol)
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3

the claims for unix under vm were field engineers requirements for ras
support ... the effort to add mainframe ras support to unix was a much
larger effort than the straight forward port to 370. aix/370 (based on
ucla locus) was operated similarly (i.e. you could run unix on the
bare iron ... you just wouldn't have all the ras support)

the other approach was cut at higher level than the virtual machine
interface.  a custom version of this had been done for AT&T
... layering unix on top of a stripped down tss/370 kernel (which
wasn't made available outside of AT&T).  i had suggested to some
of the gold people that they look at doing something similar using
aspen.

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 25 Sep 2005 10:37:24 -0600

jmfbahciv writes:

Yea.  That was a pesky problem and I don't think we (DEC) knew
enough about it.  Would IBM have had a better idea since they knew
how to do serious batch?  I wasn't clear to me that distributed
computing was the same as distributed processing (I don't think I
wrote this clearly).

ref:
http://www.garlic.com/~lynn/2005q.html#24 What ever happened to Tandem and NonStop OS

part of it was that the valley was the hot bed of all sort of
activities ... some topic drift:
http://www.garlic.com/~lynn/96.html#4a

and the other part was the company was so large ... that over a period
of years you were exposed to large number of different things.

FS was divided into something like 13 sections ... my wife worked for
the head of the section that had to do with advanced interconnect
http://www.garlic.com/~lynn/submain.html#futuresys

she then did stints co-authoring AWP39 (peer-to-peer networking
architecture ... in early SNA time-frame ... as an alternative to
SNA's centralized terminal control oriented architecture) and the JES
group ... involved in loosely-coupled (cluster by any other name)
operation.

she then got con'ed into going to POK to be in charge of
loosely-coupled architecture where she did peer-coupled shared
data architecutre
http://www.garlic.com/~lynn/submain.html#shareddata

somewhat after the incident mentioned in the reference, she was
co-author and presented corporate response to fed. gov.  request for
large, secure, campus-like distributed envrionment ... where
she formulated many of the foundation of 3-tier architecture. we then
extended that and were making customer executive presentations ...
recent reference
http://www.garlic.com/~lynn/2005q.html#38 Ethernet, Aloha and CSMA/CD

which as mentioned ... didn't earn us any points with the SAA, SNA
and/or T/R folks
http://www.garlic.com/~lynn/subnetwork.html#3tier

Prior to the referenced incident ... I had been involved in doing a
custom SMP kernel for HONE ... which was provided time-sharing
services to world-wide sales, marketing, and field support.
http://www.garlic.com/~lynn/subtopic.html#hone

the US HONE datacenter had been consolidated in cal, (with numerous
clones around the world) ... and eventually grew into possibly the
largest single-system image operation in the world. Then because of
(earthquake) disaster concerns ... there was a replica built first in
Dallas and then a second replica in Boulder (with load balancing and
fall-over across the three complexes).

With the proliferation of mid-range computers ... in the same time and
market segment as vaxes ... in the early 80s, you started seeing the
regions and then the larger branch offices installing their own 148s
and 4341s. The US HONE datacenter (and replicas) with all of its
world-wide clones interconnected with the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and then the growth of the regional and branch machines ... again all
on the internal network ... was an amazing operation in the early 80s
... not to mention the internal network itself ... which was larger
than the whole arpanet/internet from just about the beginning until
sometime mid-85.

somewhat concurrent with trying to do a new, portable operating system,
I had also started the high-speed data transport activity
http://www.garlic.com/~lynn/subnetwork.html#hsdt

that included developing an operational high-speed backbone ... but we
weren't allowed to bid on nsfnet rfp ... minor ref:
http://www.garlic.com/~lynn/internet.htm#0

i was also doing some database stuff ... having done some of the
stuff for system/r(original relational/sql)
http://www.garlic.com/~lynn/submain.html#systemr

but was also doing some support for vsli tools group out in los
gatos. they were doing a different kind of relational database that
had less structure than what has come to be RDBMS ... and looking at
its use in chip design ... including being able to integrate logical
and physical design. they were also working on first 32bit 801 risc
(there was already romp, which was 16bit 801 risc ... which was
eventually used in the pc/rt) ... and there was lots of discussion
about building a more sophisticated operating system than CPr
http://www.garlic.com/~lynn/subtopic.html#801

so part of the issue was reviving some of the stuff that we had been
doing for acorn, porting unix, and/or trying to better leverage lots
of the mainframe experience ... but apply it to a portable
implementation ... this was the heyday of lots of portable unix
workstation work going on in the valley ... as well as the stuff like
gold and aspen going on at amdahl ... recent gold/aspen reference
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS

the other issue was that i had recently done a new kernel debugging
tool that was extensively deployed internally
http://www.garlic.com/~lynn/submain.html#dumprx

... and I was starting to develop failure pattern stuff ... and
classifying some general failure causes.  for VM/370 implemented in
370 assembler ... there was a characteristic of 370 assembler that was
a common cause of a large percentage of failures ... aka programmer
having to provide management of hardware register values ... and
unusual code paths not correctly establishing register values.  I had
written another program that analysed 370 assembler source and
explicitly attempted to reconsrutct all possible code paths and look
for register used w/o loaded cases (which still didn't catch the cases
of not reloaded with expected values).

Doing a new operating system ... was an opportunity to address a whole
plethora of issues (including portability and some number of
common/frequent failure characteristics).

some of the distributed, interconnect as well as database experience
came in handy when we were doing the ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

minor related post
http://www.garlic.com/~lynn/95.html#13

and for even more drift
http://www.garlic.com/~lynn/2005q.html#25

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

tcp-ip concept

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: tcp-ip concept
Newsgroups: comp.protocols.tcp-ip
Date: Sun, 25 Sep 2005 10:55:52 -0600

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

The first sentance of the OP question asked about sending
"continuous packets" "without waiting for a response".

We aren't told what software layer the OP is operating at, and
we aren't told about the latency bandwidth product. For example,
the question might have arisen because the OP needed to be able to
send a bunch of data over a satellite connection, in which the
latency of getting back the first ACK can really kill your throughput.

as an aside ... in the 88 IETF meeting when slow-start was discussed
there was also discussion about latency issue ... and pointing out
that the latency*bandwith product was about the same for a
coast-to-coast terrestrial gbit fiber link as it was for a typical
geo-sync satellite link of the period (note that some of the newer
swarms of mini & micro sats fly at much lower latitude) ... given the
same size packets ... the number of in-flight packets were about the
same for a coast-to-coast terrestrial gbit fiber link as a
(lower-speed) geo-sync sat link.

as you point out ... the question about w/o waiting for a response
... coule also mean was it the responsibility of the application
program or the responsibility of something in the underlying protocol
stack (say stalling a send request ... w/o the application actually
requiring an explicit wait).

i've sometimes postulated that the adaptation of ACK paradigm for
complex congestion control ... which is fundamentally a rate issue
... was that many of the platforms in the 80s that had deployed tcp
stacks ... had terribly primitive timer primitives (that were either
inadequate and/or too expensive for doing a rate-based
implementation).

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

IPSEC wireless router ?

From: lynn@garlic.com
Subject: Re: IPSEC wireless router ?
Date: Sun, 25 Sep 2005 12:33:53 -0700
Newsgroups: alt.internet.wireless

David Taylor wrote:

It's not new Duane.  All you're doing is blocking traffic by port. I'm
surprised that it's new to you.

The main advantage of IPSec is the Sec part, i.e. security.  Simply
creating filters and a filter action like you are doing is the very
simplest start.  What the original poster wanted was security which to
do properly requires a PKI implementation.  Then you get mutual
authentication and encryption, none of which you have right now.

at a 94 IETF meeting in the gateway working group ... a friend
introduced something that has since come to be called VPN. my view was
that it somewhat upset the ipsec people ... since they were working on
end-to-end. the issue with ipsec has been that it required updates to
all the deployed (mostly kernel) tcp/ip protocol stacks. VPN could be
deployed w/o impacting current installed systems. eventually things
were somewhat patched over with the ipsec people labeling VPNs as
light-weight ipsec ... and lots of other people referring to ipsec as
heavy-weight ipsec. there was at least one vendor who announced a
purely vaporware vpn product that dec. ... in response to the uptake
of the concept after the ietf meeting.

to a large degree, the apperance of SSL was because of the same factor
... the difficulty with doing end-to-end ipsec because of its
impacting, existing deployed systems.

towards the end of 94, my wife and i got called in to consult with the
small client/server company that had come up with ssl ... who wanted
to do payments on their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

at the time, they had this stuff that was going to use something
called digital certificates issued by these organizations called
certification authorities (as part of something called PKI). as part
of doing payments ... we had to go around and do some end-to-end
business audits on these organizations calling themselves
certification authorities ...  some collected postings on the subject
off SSL certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

SSL implementation at the time was one-way authentication between the
server and the browser. using SSL for the webserver to payment gateway
traffic ... we required an SSL implementation that supported mutual
authentication.

however, as part of that effort, we coined the term certificate
manufacturing ... since the majority of the operations weren't
actually doing full-fledge PKIs ... no actual management and
administration of the certified information (contained in the digital
certificates) ... just the straight-forward manufacturing of the
certificates. In fact, numerous certificate-based infrastructures from
the period would rely on existing business operations for
administration of the current validaty of the certified information
(as opposed to actually deploying a full-fledge PKI). The issue then
was that for such operations ... it was quite a trivial proof to show
that the digital certificates were redundant and superfluous (if you
were relying on existing business operations for real-time validity
... then it was a very short step to having existing business
operations also providing public keys in real time).

there is now even cross-over between the original 94 vpn and the 94
ssl ... with the apparance of ssl-based VPNs.

the basic technology is asymmetric key cryptography; what one key (of
a key-pair) encodes, the other key decodes (to differentiate from
symmetric key which uses the same key for both encoding and decoding).

there are business process applications of asymmetric key cryptography
called "public key" (where one key is identified as public and made
available, and the other key is identified as private and kept
confidential and never divulated) and "digital signature" (which
involves encoding a hash of a message/document with a private key).

However, there are numerous examples of infrastructures that use
public keys, digital signatures, encrypted channels that don't involve
PKI, certification authorities, and/or digital signatures.

one of the most prevalent authentication infrastructures is RADIUS ...
starting out having been a userid/password implementation. There have
been extensions to RADIUS where public keys are registered in lieu of
passwords and digital signatures used for authentication ... totally
certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#radius

another wide-spread authentication environment is KERBEROS, found as
integral part of a large number of platforms. the original pk-init
specification had public keys being registered in lieu of passwords
and supporting digital signature authentication ... again a
certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#kerberos

pk-init specification was later upgraded to also include PKI and
certificate-based operation ... supporting the ability for total
strangers to log on to your system ... recent lengthy description
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Signature

another public key, non-PKI authentication and confidential
infrastructure with relatively wide deployment is SSH
http://www.openssh.com
http://www.ssh.com

in any case, IPSEC PKI infrastructure can carry with it a much heavier
infrastructure operation than is actually needed for public key
authentication and encryption (and even can be redundant and
superfluous compared to simple upgrades to existing management and
administrative operation).
http://www.garlic.com/~lynn/subpubkey.html#certless

HASP/ASP JES/JES2/JES3

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Date: Sun, 25 Sep 2005 20:49:51 -0600
Newsgroups: bit.listserv.ibm-main

Ed Gould wrote:

I think you are correct. SPF was developed here in Chicago at a ladies
undergarment maker. My mind is sketchy though whether it was written by
an IBM se or it could have been a joint effort. I remember our SE
trying to sell it to us. but we were out of gas, CPU wise and we
settled for FSE. I mean we were *REALLY* out of gas on our 168MP. Our
paging rate was out of sight as well. Memory in those days (IIRC) was
$10K (US) a meg and we just couldn't afford any more.

My vague recollect is that we were maxed out of memory on the 168MP,
IIRC the max was 16 meg it should have been 32 m but there was some
issue with the MP box that didn't allow that large of memory. Its' been
30 years so my memory could be wrong.

I think we went with a 3033 about 6 months later. They sort of looked
at an AP after converting to the 3033 but we just went with another
3033

I know that IBM was sent many a stand alone dump and they always came
back with "You are out of gas and need more memory" tell us something
we didn't know.