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 -0600Anne & Lynn Wheeler writes:
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)
https://www.garlic.com/~lynn/subnetwork.html#internalnet
the internal network was primarily based on networking code
developed at science center
https://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:
https://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
https://www.garlic.com/~lynn/95.html#7 Who built the Internet? (was: Linux/AXP.. Reliable?)
https://www.garlic.com/~lynn/2001e.html#12 Blame it all on Microsoft
https://www.garlic.com/~lynn/2001g.html#48 The Alpha/IA64 Hybrid
https://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002b.html#53 Computer Naming Conventions
https://www.garlic.com/~lynn/2002h.html#2 DISK PL/I Program
https://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
https://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
https://www.garlic.com/~lynn/2002k.html#48 MVS 3.8J and NJE via CTC
https://www.garlic.com/~lynn/2002k.html#49 MVS 3.8J and NJE via CTC
https://www.garlic.com/~lynn/2002q.html#31 Collating on the S/360-2540 card reader?
https://www.garlic.com/~lynn/2002q.html#35 HASP:
https://www.garlic.com/~lynn/2003.html#68 3745 & NCP Withdrawl?
https://www.garlic.com/~lynn/2003c.html#47 difference between itanium and alpha
https://www.garlic.com/~lynn/2003f.html#0 early vnet & exploit
https://www.garlic.com/~lynn/2003g.html#51 vnet 1000th node anniversary 6/10
https://www.garlic.com/~lynn/2003i.html#32 A Dark Day
https://www.garlic.com/~lynn/2003o.html#68 History of Computer Network Industry
https://www.garlic.com/~lynn/2004b.html#53 origin of the UNIX dd command
https://www.garlic.com/~lynn/2004g.html#35 network history (repeat, google may have gotten confused?)
https://www.garlic.com/~lynn/2004g.html#39 spool
https://www.garlic.com/~lynn/2004h.html#2 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004n.html#45 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#60 JES2 NJE setup
https://www.garlic.com/~lynn/2004o.html#61 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2005e.html#12 Device and channel
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/subpubkey.html#radius
my rfc index
https://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 | https://www.garlic.com/~lynn/
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 -0600WM wrote:
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
https://www.garlic.com/~lynn/98.html#18 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/98.html#51 Mainframes suck? (was Re: Possibly OT: Disney Computing)
https://www.garlic.com/~lynn/99.html#16 Old Computers
https://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004.html#43 [Fwd: Re: Mainframe not a good architecture for interactive w
https://www.garlic.com/~lynn/2004b.html#10 Mars Rover Not Responding
https://www.garlic.com/~lynn/2004c.html#28 Moribund TSO/E
https://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:
https://www.garlic.com/~lynn/2005o.html#45 Article: The True Value of Mainframe Security
https://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security
https://www.garlic.com/~lynn/2005o.html#47 Article: The True Value of Mainframe Security
https://www.garlic.com/~lynn/2005p.html#0 Article: The True Value of Mainframe Security
https://www.garlic.com/~lynn/2005p.html#13 One more about SYRES Sharing
https://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005p.html#16 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS
https://www.garlic.com/~lynn/2005p.html#18 address space
https://www.garlic.com/~lynn/2005p.html#19 address space
https://www.garlic.com/~lynn/2005p.html#20 address space
https://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor
https://www.garlic.com/~lynn/2005p.html#34 What is CRJE
https://www.garlic.com/~lynn/2005p.html#37 CRJE and CRBE
https://www.garlic.com/~lynn/2005p.html#38 storage key question
https://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: winscape? Newsgroups: alt.folklore.computers Date: Tue, 20 Sep 2005 09:36:23 -0600Andrew Swallow writes:
recent posting on some aspects of internal network
https://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
https://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.
https://www.garlic.com/~lynn/2002k.html#12
we weren't allowed to bid on the rfp
https://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:
https://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:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://www.garlic.com/~lynn/subtopic.html#545tech
invented over 35 years ago
https://www.garlic.com/~lynn/submain.html#sgml
references tracing html to sgml & waterloo script (and thus back
to gml)
https://www.garlic.com/~lynn/2002b.html#46 ... the need for a Meseum of Computer Software
https://www.garlic.com/~lynn/2004l.html#72 Specificying all biz rules in relational data
https://www.garlic.com/~lynn/2005e.html#34 Thou shalt have no other gods befreo the ANSI C standards
https://www.garlic.com/~lynn/2005f.html#49 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005k.html#58 Book on computer architecture for beginners
https://www.garlic.com/~lynn/2005l.html#10 who invented CONFIG/SYS?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: winscape? Newsgroups: alt.folklore.computers Date: Tue, 20 Sep 2005 09:46:29 -0600greymaus writes:
misc. collected posts on human & "e" signatures
https://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):
https://www.garlic.com/~lynn/aadsm3.htm#cstech cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech2 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aepay7.htm#etsi fyi ... Comments requested on ETSI Draft TR "XML format for signature policies"
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aepay10.htm#2 German federal employees get digital signatures
https://www.garlic.com/~lynn/aepay10.htm#7 UNCITRAL Electronic Contracting Project
https://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting)
https://www.garlic.com/~lynn/aepay10.htm#71 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential downside of TCPA
https://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
https://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
https://www.garlic.com/~lynn/aadsm14.htm#19 Payments as an answer to spam (addenda)
https://www.garlic.com/~lynn/aadsm14.htm#43 PKI "not working"
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#39 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card
https://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2001g.html#25 Root certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#1 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Rick Troth writes:
two x-posts
https://www.garlic.com/~lynn/2005p.html#26 What ever happened to Tandem and NonStop OS ?
https://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
https://www.garlic.com/~lynn/submain.html#systemr
wrote a departing note when he left sjr to go to tandem
https://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
https://www.garlic.com/~lynn/subnetwork.html#cmc
some other posts in the original thread
https://www.garlic.com/~lynn/2005o.html#32 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005o.html#37 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005o.html#43 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#3 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#4 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#7 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#10 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#11 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#23 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#30 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#39 What ever happened to Tandem and NonStop OS ?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
the internal network
https://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:
https://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).
https://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
https://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
https://www.garlic.com/~lynn/2005q.html#3
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Allan Scherr wrote:
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
https://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
https://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).
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 -0600Andrew Swallow writes:
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
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/subtopic.html#fairshare
some related posts on benchmarking and preparing the resource manager
for release
https://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
https://www.garlic.com/~lynn/subtopic.html#smp
misc. past posts about unbundling
https://www.garlic.com/~lynn/submain.html#unbundle
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
https://www.garlic.com/~lynn/2000g.html#40 No more innovation? Get serious
https://www.garlic.com/~lynn/2002f.html#19 When will IBM buy Sun?
https://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
https://www.garlic.com/~lynn/2003e.html#26 MP cost effectiveness
https://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
https://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005p.html#23 What ever happened to Tandem and NonStop OS ?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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 | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/x959.html#aads
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600echomko_at_@polaris.umuc.edu (Eric Chomko) writes:
at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
besides unbundling announcement on 6/23/69
https://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
https://www.garlic.com/~lynn/94.html#44 bloat
https://www.garlic.com/~lynn/96.html#20 1401 series emulations still running?
https://www.garlic.com/~lynn/99.html#231 Why couldn't others compete against IBM?
https://www.garlic.com/~lynn/2002c.html#0 Did Intel Bite Off More Than It Can Chew
https://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
https://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 | https://www.garlic.com/~lynn/
From: lynn@garlic.com Newsgroups: microsoft.public.security Subject: Re: IPSEC with non-domain Server Date: Thu, 22 Sep 2005 14:41:35 -0700Steven L Umbach wrote:
with kerberos performing digital signature validation using the on-file public keys for something you have authentication.
from 3-factor authentication paradigm
https://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
https://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
https://www.garlic.com/~lynn/aadsm20.htm#42
https://www.garlic.com/~lynn/aadsm21.htm#2
https://www.garlic.com/~lynn/aadsm21.htm#12
In response there was the creation of relying-party-only digital
certificates
https://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).
https://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
https://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).
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:
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)
https://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 | https://www.garlic.com/~lynn/
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-mainSkip Robinson wrote:
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
https://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 synchronization 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)
https://www.garlic.com/~lynn/subtopic.html#smp
and then of course there is SCIDS
https://www.garlic.com/~lynn/2000d.html#5 Definition of SHARE & SCIDS Requested
https://www.garlic.com/~lynn/2000d.html#6 Definition of SHARE & SCIDS Requested
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-mainand 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.
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 -0600Roberto Waltman writes:
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)
https://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
https://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005d.html#11 Cerf and Kahn receive Turing award
https://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
https://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
https://www.garlic.com/~lynn/subtopic.html#801
for even more drift:
https://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
https://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
https://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
https://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
https://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2004j.html#16 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
https://www.garlic.com/~lynn/2004o.html#65 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2005c.html#6 [Lit.] Buffer overruns
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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
https://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
https://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 CAT4 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 CAT4 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:
https://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
https://www.garlic.com/~lynn/2000f.html#38 Ethernet efficiency (was Re: Ms employees begging for food)
https://www.garlic.com/~lynn/2000f.html#39 Ethernet efficiency (was Re: Ms employees begging for food)
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002.html#38 Buffer overflow
https://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#9 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
https://www.garlic.com/~lynn/2002q.html#41 ibm time machine in new york times?
https://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003j.html#46 Fast TCP
https://www.garlic.com/~lynn/2003k.html#57 Window field in TCP header goes small
https://www.garlic.com/~lynn/2003p.html#13 packetloss bad for sliding window protocol ?
https://www.garlic.com/~lynn/2004e.html#13 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2004e.html#17 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
https://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
https://www.garlic.com/~lynn/2005i.html#43 Development as Configuration
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600JO.Skip.Robinson@ibm-main.lst wrote:
recent posting ref.
https://www.garlic.com/~lynn/2005p.html#38 storage key question
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 -0600ref:
the whole saa & terminal emulation forever
https://www.garlic.com/~lynn/subnetwork.html#emulation
overflowed into a number of areas.
romp/pcrt
https://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.
https://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
https://www.garlic.com/~lynn/96.html#16 middle layer
https://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
https://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600Anne & Lynn Wheeler writes:
... 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 | https://www.garlic.com/~lynn/
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 -0600roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
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 | https://www.garlic.com/~lynn/
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 -0700Martin Høst Normark wrote:
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
https://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.
https://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
https://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 accessible 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.
https://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
https://www.garlic.com/~lynn/subpubkey.html#signature
from 3-factor authentication
https://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).
https://www.garlic.com/~lynn/aadsm21.htm#3 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
some past posts on digital signature dual-use attack
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
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 -0600jmfbahciv writes:
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
https://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 successful 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 | https://www.garlic.com/~lynn/
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 -0600Jim Brooks writes:
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:
https://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 ..
https://en.wikipedia.org/wiki/Intel_ASCI_Red
http://www.sandia.gov/ASCI/Red/
in the mid-90s, 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 | https://www.garlic.com/~lynn/
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:
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 | https://www.garlic.com/~lynn/
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 -0600jmfbahciv writes:
part of it was that the valley was the hot bed of all sort of
activities ... some topic drift:
https://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
https://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
https://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 environment ... where
she formulated many of the foundation of 3-tier architecture. we then
extended that and were making customer executive presentations ...
recent reference
https://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
https://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.
https://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
https://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
https://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:
https://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)
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/subtopic.html#hacmp
minor related post
https://www.garlic.com/~lynn/95.html#13
and for even more drift
https://www.garlic.com/~lynn/2005q.html#25
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0600roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
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 | https://www.garlic.com/~lynn/
From: lynn@garlic.com Subject: Re: IPSEC wireless router ? Date: Sun, 25 Sep 2005 12:33:53 -0700 Newsgroups: alt.internet.wirelessDavid Taylor wrote:
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
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://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
https://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
https://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
https://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).
https://www.garlic.com/~lynn/subpubkey.html#certless
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-mainEd Gould wrote:
370/158 had integrated channels ... the microcode engine was shared between integrated channel microcode and 370 microcode. for 303x, they took 158 microcode engine kept the integrated channel microcode and removed the 370 microcode ... for the 303x channel director. the 3031 was the 158 engine with just the 370 microcode engine and the integrated channel m'code removed. A uniprocessor 3031 is sort of a two processor smp ... with one engine dedicated to 3031 370 microcode and one engine dedicated to 303x channel director.
3032 was 168-3 reconfigured to use the 303x channel director.
3033 started out being the 168 wiring diagram mapped to faster chip technology. this started out being approx. 20percent faster than 168. however some re-optimization of the circuits eventually resulted in the 3033 being about 50percent faster than 168.
pok had an interestion situation with endicott and 4341s. 4341 was faster and cheaper than 3031 ... and cluster of six 4341s were faster than 3033 and also cheaper (96mbytes aggregate and total 36 channels).
two separate 3033s could each have max. of 16mbytes (32mbyte max) ... but a two-processor 3033 smp was limited to 16mbytes max.
3033 eventually announced a hack to get 32mbyte real memory. 370 page table entry was 16bits, 12bits for (4k) page numers (4096 4kpages, 16mbytes total), two additional defined bits, two undefined bits. virtual addressing was 24bits, real addressing was (mostly) 24bits, but they took one of the undefined bits to allow for 8192 4k (real) pages (32mbyte total). there was still stuff that had to be below the 16mbyte (real) line ... but you could have virtual pages above the 16mbyte line and use idal CCWs to do i/o above the line. there was some hacks to move pages from above the line to below the line (when necessary).
annc. avail. IBM 3033 77-03 78-03 12 VERY LARGE S/370+EF INSTRUCTIONS IBM 3033MP 78-03 79-09 18 MULTIPROCESSOR OF 3033 IBM 3033AP 80-06 80-08 02 3033 ATTACHED PROCESSOR IBM 3033 80-06 81-10 16 Ext. Addr.=32MB REAL ADDR.;MP ONLYmisc. past posts that mention 4341 and 3033
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: Mon, 26 Sep 2005 10:24:37 -0600"JJ" writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: HASP/ASP JES/JES2/JES3 Newsgroups: bit.listserv.ibm-main Date: Mon, 26 Sep 2005 17:19:20 -0600Ed Gould wrote:
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: Mon, 26 Sep 2005 22:43:20 -0600"YKhan" writes:
this has oblique mention to 386sx hasten end of 286 era in the
fall of 88.
http://www.pcmag.com/article2/0,1895,1162496,00.asp
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How To Abandon Microsoft Newsgroups: alt.conspiracy,alt.activism,sci.crypt,alt.politics Date: Mon, 26 Sep 2005 23:15:17 -0600Mxsmanic writes:
as an undergraduate, i gave presentation on the subject at a mainframe user group meeting in fall68 held in Atlantic City. technology was widely used on secure mainframe deployments in the 60s & 70s.
there have been some number of conferences over the past year speculating that security for current environments might have to wait on widespread deployment of the same technology (back to the future).
random sprinkling of misc. references mentioning the issue
http://therealadam.com/weblog/archives/2005/01/09/virtualization-as-security-savior/
http://www.networkworld.com/news/2006/030706-citibank-network-breach.html
http://www.infoworld.com/article/04/11/15/HNamdvirtual_1.html
http://www.infoworld.com/article/05/08/22/34TCvmware_1.html
http://castlecops.com/article-6242-nested-0-0.html
http://storage.itworld.com/4620/050804emcceo/
http://www.hp.com/products1/unix/operating/sep05.html
http://www.intel.com/technology/computing/vptech/
http://www.forrester.com/Research/Document/Excerpt/0,7211,36574,00.html
http://www.internetnews.com/dev-news/article.php/3462351
http://www.securitypark.co.uk/article.asp?articleid=24207&CategoryID=11
http://www.virtual-strategy.com/article/articleview/1130/1/6/
http://www.vmware.com/community/thread.jspa?threadID=21676&tstart=0
http://www.xbitlabs.com/news/other/display/20040908094339.html
http://www.softricity.com/news/webinar-archive.asp?eventID=coresecurity
http://www.veritest.com/services/virtualization.asp
http://www.hardwarecentral.com/hardwarecentral/reports/5798/1/
you can get a lot more hits by using terms security, virtualization
old past with small part of the fall68 presentation ... mostly about
significant thruput performance I had obtained by rewriting major
portions of the kernel over the previous couple months (vendor was
picking up the changes and turning around and shipping in standard
product).
https://www.garlic.com/~lynn/94.html#18
back in the old days of free software ... before the transition for
charging ... misc. postings on some of the transitions from the old
days of free software and the age of charging for software
https://www.garlic.com/~lynn/submain.html#unbundle
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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: Mon, 26 Sep 2005 23:52:08 -0600on the other hand ... here are some raw chip numbers from 1990 (as opposed to pc systems)
CA's CA's CA's CA's CA's SHARE
CPU 1986 1987 1988 1989 1990 1990
INTEL 80186/286 971622 1840928 2506136 2924733 3077693 36%
INTEL 808x 2374099 2546252 2232084 1913469 1456441 17%
INTEL 80386 19859 231767 625134 893610 949963 11%
INTEL 80486 0 0 0 301 64699 1%
MOTOROLA 68xxx 1921562 1787042 1354593 1378959 1273736 15%
UNKNOWN/OTHER 0 813485 664137 570155 653013 697567 8%
(includes Intel)
=============== 6100627 7070126 7325753 8103435 8620257 100%
--
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: Tue, 27 Sep 2005 19:17:18 -0600archmage@sfchat.org (Nate Edel) writes:
for a time, there was a conference room/lab in bldg. 61G ... with a number of machines interconnected with DataHub
at some point it was decided to cancel the project and allow the work product produced by people in provo to retained by the people that had produced it. total conjecture how it was used by the people in provo?
random past postings mentioning DataHub
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
https://www.garlic.com/~lynn/2000g.html#40 No more innovation? Get serious
https://www.garlic.com/~lynn/2002f.html#19 When will IBM buy Sun?
https://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
https://www.garlic.com/~lynn/2003e.html#26 MP cost effectiveness
https://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?
https://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005p.html#23 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#9 What ever happened to Tandem and NonStop OS ?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Callable Wait State Date: Wed, 28 Sep 2005 14:12:52 -0600 Newsgroups: bit.listserv.ibm-mainCharles Mills wrote:
i've frequently asserted that one of the issues that gave rise to slow-start windows for tcp delay/congestion compensation was the primitive state of timer primitives on many of the platforms (that were either inadeqaute and/or too expensive for doing rate-based pacing implementation).
sort of as part of hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt
we had done some high-speed backbone ... that included rate-based pacing management for combination of delay & congestion management ... running in the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
the internal network had been larger than the internnet/arpanet from
just about the beginning (of both) until possibly mid-85.
https://www.garlic.com/~lynn/subnetwork.html#internet
one of the issues was that we weren't allowed to bid on the original
NSFNET backbone
https://www.garlic.com/~lynn/internet.htm#0
aka ... the great 1/1/83 switchover was a technology change to internetworking protocol ... but it was the NSFNET backbone that provided the internetworking backbone between different networks ... that possibly represents the actual operational birth of the modern internet.
minor references
https://www.garlic.com/~lynn/2002k.html#12 NSFNET Program Announcement
https://www.garlic.com/~lynn/2000e.html#10 NSFNET Award Announcement<
random past postings mentioning rate-based pacing:
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful amachine was it?
https://www.garlic.com/~lynn/2002k.html#56 Moore law
https://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
https://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
https://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
https://www.garlic.com/~lynn/2003j.html#46 Fast TCP
https://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
https://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
https://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004q.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
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: Wed, 28 Sep 2005 20:23:47 -0600Joe Seigh writes:
an issue was that the vertical microcode engines were getting about ten microcode instructions per 370 instruction ... and every microcode engine tended to be unique/different. fort knox was converting this plethera of microcode engines all to 801 base. however by the 4341 follow-on eare, the technology was starting to be available to implement some amount of the 370 instruction set directly in silicon. the result was that direct silicon implemented 370 was going to be faster than continuing the microcoded emulation paradigm ... even using a 801 risc microprocessor. i helped with some of the sections of the document that killed the 801 follow-on to 4341 ... in support of direct silicon implementation.
801/ROMP was a joint research & office products division (OPD) to do a follow-on to the OPD displaywriter. ROMP had the original, traditional 801 hardware/software design trade-offs ... with single integrated domain (no hardware protection features) with close, proprietary CP.r operating system with everything written in PL.8. I believe the business analysis eventually was that while ROMP price/performance was great ... the entry level configuration was still more expensive than the top of the displaywriter market price-point. In any case, the displaywriter follow-on project got killed. As a strategy to save the group in Austin, it was decided to retarget the hardware platfrom to the unix workstation market. The company that had done the AT&T unix for PC/IX was hired to do a similar port to ROMP. However, you still had all these PL.8 programmers ... so the scenario was to create a project called VRM ... which would be an abstract virtual machine implementation in PL.8 ... and the UNIX port would be done to the abstract virtual machine interface ... rather than to the bare hardware.
hardware protection had to be added to 801 in order to support the unix execution model (as opposed to the closed, proprietary cp.r/pl.8 model). also the claim for doing the VRM+unix hybrid was that it could be done significantly faster, cheaper, and fewer resources than a direct unix port to the bare iron. this was subsequently disproved when the BSD port was doine to the bare iron for "AOS" offering on the pc/rt.
some number of collected 801, romp, rios, power/pc, etc postings
https://www.garlic.com/~lynn/subtopic.html#801
now there was some crippling of the subsequent RIOS/RS6000 systems
... not particularly the processor ... but the overall systems.
RS6000 moved to microchannel and the 6000 group were mandated to use
PS/2 microchannel cards ... not so much to cripple them vis-a-vis
mainframe midrange ... but to help with the PS2 card volumes. The
following has a drawn out descussion of the microchannel 16mbit t/r
card for the RS/6000 ... which was actually slower than the 16bit ISA
4mbit t/r card that had been developed for the PC/RT (there were
similar issues with many of the other PS2 microchannel cards)
https://www.garlic.com/~lynn/2005q.html#20 Ethernet, Aloha and CSMA/CD
now there is rumored to have been some flavor of attempting
to protect mainframe operation in the wake of the following
https://www.garlic.com/~lynn/95.html#13
when my wife and I were told that we couldn't work on configurations
with more than four processors (somewhat numerical intensive wasn't
considered much of a threat ... but moving into hardcore commercial
database processing became much more of an issue). when we were doing
ha/cmp, we had also coined the terms disaster survivability (as
opposed to disaster/recovery) and geographic survivability ... and I
got asked to write a section in the corporate continuous availability
strategy document. Both Rochester and POK complained about the section
(they couldn't meet) and it was removed. some collected ha/cmp
postings:
https://www.garlic.com/~lynn/subtopic.html#hacmp
Possibly the most flagrant scenario of such, was POK trying to protect
their mainframe machines from Endicott's mid-range 4341
mainframe. 4341 had higher thruput and cheaper than POK's 3031. A
cluster of six 4341s also had higher thruput and cheaper than a POK's
3033. a recent posting discussion some of the 4341/3033 issues ...
that also included a large number of past postings on the subject
https://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How To Abandon Microsoft Newsgroups: alt.conspiracy,alt.activism,sci.crypt,alt.politics Date: Wed, 28 Sep 2005 20:48:01 -0600Bryan Olson writes:
much of the virtualization work from the 60s, referenced in the
previous post
https://www.garlic.com/~lynn/2005q.html#34 How To Abandon Microsoft
was done on the 4th floor 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech
the projects on both the 4th and 5th floors somewhat trace a common heritage back to ctss.
we used to have some sort of friendly rivalries. They liked to point to the total number of Multics installation (over the complete lifetime of the project) ... and also the security & integrity reputation..
sort of my response ... was that the integrity of the stuff done on
the 4th floor was not only good enuf for a lot of sensitive
environments ... but also good enuf for the basis of some number of
commercial timesharing services ... even with customers in highly
competitive financial market segment (i.e. real money involved)
https://www.garlic.com/~lynn/submain.html#timeshare
and when people think of the corporate dataprocessing ... they primarily think of the big commercial batch systems and not particularly timesharing. i've explained it as the number of customer batch systems totally dwarfing the total number of customer interactive, timesharing systems. Futhermore, the total number of customer interactive timesharing installations was larger than the total number of internal corporate timesharing installations.
I used to have this hobby of personally building, maintaining, and distributing custom versions of this timesharing system to internal installations (which was a much smaller number than the total number of all internal timesharing installations). However, at one point the total number of systems that I was distributing to ... was about the same number of total systems that had ever run multics. It wouldn't be fair to compare the efforts of large product group supporting large number of customers to the multics group ... since the customer base and the number of people involved were so much larger. It was much more of a fair comparison between what I was doing by myself to what the Multics group were doing.
I once joked ... looking at some code in unix in the late 80s .. that I thot I had eliminated that code when I was doing kernel rewrites as an undergraduate in the late 60s (twenty years earlier).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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: Thu, 29 Sep 2005 08:11:20 -0600Tony Hill writes:
previous post giving x86 chip shipments in the late 80s thru sept.
1990 ... I'm not actually positive whether the numbers given for 1990
where just for up thru Sept (when the numbers were compiled) or
includes projected for ye1990
https://www.garlic.com/~lynn/2005q.html#35
RIOS followed ROMP. it was same/original 801 design .. modulo having to add hardware protection domains ... since the original from the 70s was single domain and also inverted tables with 16 segment registers for virtual memory. at advanced adtech conference in the 70s, i had brought up the fact that it had provisions for limited virtual memory objects (using 16 segment register implementation). their reply was that there were no hardware protection domains, that application code would be able to execute inline segment register change operations as easily as it could change general purpose registers (any protection being provided by pl.8 compiler/libraries only allowing correct code and cp.r only loaded validly generated pl.8 code for execution). rios also provided no cache consistency ... not between I & D caches and not for any smp configurations ... that is one reason my wife and i resorted to the ha/cmp design point for being able to do rios scale-up.
I have paperweight on my desk that was given out in Austin to
commemorate RIOS announce ... which has title:
IBM AWD Austin - GTD Burlington
POWER Architecture
and below the chips: 150 million ops, 60 million flops, 7 million
transisters).
the executive my wife and I reported to when we were doing ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
then moved over to headup somerset ... the ibm, motorola, apple, et al ... effort. i somewhat characterized it as being able to add 88k cache consistency and smp memory bus to a 801 design. this became 6xx, et all ... aka powerpc.
misc. past 801, romp, rios, fort knox, somerset, etc posts
https://www.garlic.com/~lynn/subtopic.html#801
the following from
http://applemuseum.bott.org/sections/ppc.html
The first PowerPC processors were to be designed at Somerset and would
arrive at Apple in one year and Apple would introduce the
PowerPC-based Power PowerMacintosh series on the Mac's 10th
anniversary, January 24, 1994.
.. snip ...
and
http://www.answers.com/topic/powerpc
from above:
Word
PowerPC Year Size # of Macintosh
Model Intro. (bits) Trans. Models
970 2003 64 52M G5
7400 1999 32 10.5M G4
750 1997 32 6.4M G3
740 1997 32 6.4M G3
604e 1996 32 5.1M
603e 1996 32 2.6M
603 1995 32 1.6M
604 1995 32 3.6M
602 1995 32 1M
601 1993 32 2.8M
.. snip ...
here is another early perspective from bull's viewpoint
http://febcm.club.fr/english/power_pc_products.htm
it mentions rochester decided to not go with 620 ... but instead going their own way.
I've frequently described 801 (simple and KISS) was a reaction to the
horribly complex FS project ... which was conceled before it was ever
announced
https://www.garlic.com/~lynn/submain.html#futuresys
the folklore was then that some number of the FS diehards went off to rochester and did s/38. fort knox era circa 1980 would have moved their product onto an 801 processor (coming full circle). however that strategy died also. s/38 morphed into as/400 with cisc processor ... but as/400 finally did move to 801 processor with the 630.
this description somewhat jumbles story about use of "POWER" ...
since POWER shows up from the earliest period for RIOS (i.e.
including above mentioned paperweight). powerpc was to differentiate
that somerset/6xx stuff had PC design point ... not high performance
numerical intensive workstation
https://en.wikipedia.org/wiki/PowerPC
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Instruction Set Enhancement Idea Newsgroups: bit.listserv.ibm-main Date: 29 Sep 2005 08:29:09 -0700Edward E. Jaffe wrote:
Basically, (OS/VS2) SVS was MVT layed out in 16mbyte address space (AOS2 prototype for SVS was done on 360/67 with a little bit of low-level code for handling the page faults and CCWTRANS borrowed from cp/67 to do the virtual->real translation for CCWs).
The transition to (OS/VS2) MVS really caused problems since the real-memory-only, common address space was institutionalized in the entrenced pointer-passing convention. It required the MVS kernel being (8mbyte) part of every (16mbyte) address space ... theoretically leaving only 8mbytes left for application. However, with the movement of various subsystems to their own (separate) virtual address space ... the common segment kludge had to be done allowing the pointer-passing paradigm to continue. Prior to 3033 dual-address space ... it wasn't uncommon to find large installations with 4-5mbyte common areas ... frequently leaving only 3mbytes (out of 16mbytes) for actual application use.
Infrastructures that grew up with multiple virtual address spaces were heavily message passing based ... rather than pointer passing paradigm (which implied access in the same address space)
dual-address space on 3033 and access registers in 370-XA were provisions for continued support of pointer-passing paradigm ... allowing the storage area being pointed at, to exist in a different (virtual) address space.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel strikes back with a parallel x86 design Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips Date: Thu, 29 Sep 2005 10:24:44 -0600Del Cecchi writes:
they hired the group that had done the AT&T port to the ibm/pc for pc/ix ... to do one for (office product division displaywriter) romp.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel strikes back with a parallel x86 design Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips Date: Thu, 29 Sep 2005 11:43:14 -0600Del Cecchi writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel strikes back with a parallel x86 design Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips Date: Thu, 29 Sep 2005 11:54:40 -0600as an aside, i trip across refeence that a good 386 system was faster than the (morphed displaywriter 16bit romp) pc/rt
prev. post with chip volume numbers from sept. 90
https://www.garlic.com/~lynn/2005q.html#35 Intel strikes back with a parallel x86 design
sjmn news article summary about x86 vis-a-vis 68k from april '89
Chip Wars:
1972 Intel 8008 3,500 transistors; 8-bit
1978 Intel 8086
1979 Intel 8088 29,000 transistors; 16-bit
Motorola 68000 68,000 transistors
1981 IBM picks Intel 8088
Apple picks Motoroloa 68000
1982 Intel 80286 130,000 transistors
1983 Motorola 68010 (adopted by Sun, H-P, Apollo)
1984 Motorola 68020 195,000 transistors 32-bit
1985 Intel 80386 32-bit; IBM adopts it for PS/2 line
1987 Motorola 68030
1988 Intel 80486 (1-million transistor mark broken)
Motorola unexpectedly releases advance details of 68040
Intel will take robe off 80486 contender today
Motorola is tying the gloves on the 68040
Time to watch some of America's most sophisticated technology companies
- slug it out over who will build brains of tomorrow's computers
- Microprocessor Wars, round 4
- contenders will find markets have undergone important changes
. 2-company contest has turned into a "bench-clearing brawl"
Drew Peck, Donaldson, Lufkin & Jenrette analyst, New York
- "Amount of confusion out there is as high as I've ever seen it."
- "Motorola and Intel are well-situated to become the
microprocessor standards of the future.
... it's a toss-up as to who's going to come out on top."
68040 and 80486 are very similar from technology point of view
- predictable extensions of familiar product lines
- promise whopping dose of industry's most sought-after commodity
. Speed (2-3 times as fast)
. approaching multi-million dollar mainframes
- First computers to use them expected in mid-1990
- extraordinary design feats
. 68040: 1.2 million transistors
. 80486: 1.1 million transistors
. 80386: 275,000 transistors (for comparison)
- High-level of integration
. Space for frequently used data and instructions
. Floating point math units
Chip customers are NOT similar
- Intel: adopted by IBM and Compaq
- Motorola: Apple, Sun, Hewlett-Packard
- 1988: Intel and Motorola neck-and-neck in sales of 32-bit processors
- Neither new chip is likely to give one company an advantage
- But computer markets are beginning to skew the race
- Intel may have trouble finding a home for the 486 in PC market
. Computer makers are only now absorbing the 386
. $1,000 price for 486 pushes computer to $15,000 range
. Computer makers may decide the extra power isn't worth it
. The applications for that power aren't there yet
("How much faster can my word processor run?")
- Some think Intel will begin poaching on Motorola territory
. technical workstations
. "... a chance to sway Motorola customers"
. "Problem is all that RISC stuff got there a year ago."
. "Not clear all that business hasn't been spoken for"
- Michael Slater, Microprocessor Report
Sequent Computer Systems, Beaverton, Oregon
- early Intel customer for 486
- plans to string the chips together into a mainframe
RISC
- Sun and Mips elbowed their way into the microprocessor market
- Some limitations:
. Not appropriate for all computing applications
- Quick speed fix of RISC has proved to be an irresistible attraction
. Put pressure on Motorola 68000 line
. "If we waited for Motorola, we'd still be waiting"
- Bill Keating, Sun director of technology marketing
- Motorola introduced it's own RISC processor
- Intel, well known RISC-detractor, rolled out its 80860
- Betting on both horses
. Forestall the RISC competitors
. Use faster conventional products to prevent further defections
Motorola is the company with the most to lose
- working overtime to smooth customer feathers
- gave reporters an inside peek at the 68040
. timed to coincide with Intel 486 announcement
- Souped up versions of the 68030 could, theoretically,
keep up with the RISC chips
Bill Keating, Sun
- 68040 and 80486 "are based on technology that's 10 years old"
- "They're serving the needs of software, more than hardware"
- How popular RISC becomes will prove the variable
. whether these chips represent a breakthru in technology
. or the end of the line
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel strikes back with a parallel x86 design Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips Date: Thu, 29 Sep 2005 12:03:58 -0600and another news article summary from a little earlier, sept. 88
• In a few months Intel will introduce its 80486 microprocessor
- mainframe on a chip
- 1 million transistors
- equal to low-end IBM 3090
• New age of personal mainframes
• Microprocessors will replace central processing units in mainframes
• Today Intel directly sells 20% of world's microprocessors
- 70% of all PCs use Intel technology
- 386 chip could be in up to half "IBM-type" PCs next year
• Intel's business is booming
- first half 1988 earnings up 211% to $224 million
- on revenue up 64% to $1.4 billion
• The 486 chip should sell initially in 1989 for about $1,500
- expect 486 based PC in 1990 for about $20,000
- such a PC should be able to run dozens of simultaneous large apps
- will greatly concentrate power into the executive suite
• Competing RISC designs promise ten-fold speed-ups
- Sun's Sparc chip is licensed by AT&T, Unisys and Britain's ICL
- MIPS Computer Systems RISC chip is licensed to Tandem Computers
- Sun and MIPS RISC chips will be produced and marketed by
TI, LSI Logic, Fujitsu, Cypress Semiconductors and others
- Motorola and Intel have introduced their own RISC chips
• Superfast chips of any design will open new opportunities in
application areas
- Intel safe in office applications thanks to $12 billion worth of
IBM-type PC programs but other areas are more open
• Mainframes could be built using these microprocessors
- standardized chips encourage mainframe cloning
- startups spared the up front costs of developing CPU and S/W
- Zenith Data Systems and Compaq Computer are planning to move
into minicomputers and mainframes using Intel's chips
- Intel already packages its chips into systems ranging from
printed-circuit boards to finished PCs
- Intel is in a 50-50 joint venture with Siemens to build a
fault-tolerant mainframe called Biin (buy-in?)
- Biin is due out this October
- Intel's systems business is 27% of total revenue this year and
is expected to be 33% in 1990
• Intel is improving its manufacturing capability
- closed 8 outdated plants
- spending $450 million this year on leading-edge equipment and
new plants
- let 25% of its workforce go, 6,000 workers and managers
- revenue per employee doubled last year to $100,000
• Parallel systems promise even better price/performance
- Intel has sold nearly 150 hypercubes containing 8 or more MPUs
- Hypercube can outperform a Cray at certain tasks
- Sequent Computer Systems of Beaverton, Oregon builds parallel
systems of mainframe performance that sells for one tenth the price
- Sequent's 120 MIP Symmetry system supports hundreds of simultaneous
users, putting it in the range of IBM's biggest 3090
- But Sequest's Symmetry costs $5,000 per MIP and IBM costs $120,000
- Intels biggest parallel system delivers 512 MIPs with 128 MPUs,
more than any commercial maimframe
- With 32 MPUs, Intel's IPSC machine outperforms a Crey X-MP/12
by 40% (100 megaflops vrs 70 megaflops)
- Cost per megaflop: Intel=$10,000; Cray=$100,000
- Others are selling parallel systems built from Motorola, Intel,
Inmos or National Semiconductor MPUs
- Boston's Stratus Computer, based on Motorola MPUs, has installed
1,444 systems at places such as Gillette, Visa International, and
the National Association of Securities Dealers
- Stratus' sales were $184 million in 1897 and have been compounding
at roughly 50% a year
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel strikes back with a parallel x86 design Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips Date: Thu, 29 Sep 2005 14:03:17 -0600nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
although there was the issue with the pc/rt ... what to do with all the pl.8 programmers that had been on the displaywriter project ... and coming up with VRM for the pl.8 coders to build an abstract virtual machine ... for unix to be ported to (rather than the bare iron) ... which in turn led to the fact that every new device ... required a pl.8/vrm device driver in addition to a new (non-standard) unix device driver
i think that it was Bob Evans who asked my wife to audit the 8100 ... which helped finally get it killed.
she also contributed to getting RP3 killed.
when we weren't allowed to bid on nsfnet
https://www.garlic.com/~lynn/2002k.html#12 ... nsfnet backbone RFP announce
https://www.garlic.com/~lynn/2000e.html#10 ... nsfnet rfp award announce
she went to director of NSF and got an audit of the backbone we were
running. This led to a letter (from NSF, co-signed by some other fed
agencies) to the head of research (copying the ceo and a couple
others) saying that what we had operational was at least five years
ahead of all bids to build something new. minor ref
https://www.garlic.com/~lynn/internet.htm#0
this contributed to her being asked to leave research ... and her transfer to FSD. Shortly later when research was making the rounds of the organizations that had been funding RP3 (looking for more money), FSD asked her to audit the project. Which in turn led to no new RP3 funding from FSD (which helped hasten RP3 demise).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel strikes back with a parallel x86 design Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips Date: Thu, 29 Sep 2005 14:41:42 -0600ref:
for arcane references ... 8100
https://en.wikipedia.org/wiki/IBM_8100
rp3 reference ... even slightly on-topic with respect to
parallel operation
http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV1005.html
of course with respect to earlier posts
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/2005q.html#38
the part of having stuff transferred to kingston for numerical intensive and being told we couldn't work on anything with more than four processors ... may have had some leftover issues because of RP3 ... in addition to the issue of encroaching on industrial strength commercial data processing.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Intel strikes back with a parallel x86 design Newsgroups: comp.arch Date: Fri, 30 Sep 2005 00:22:21 -0600nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
the mainstream operating system started out real-mode ... and then initial move to virtual memory was when 370 introduced 24-bit virtual address space support ... and involved mapping all the real-mode stuff into a single 16mbyte virtual address space.
the second iteration involved giving every applicaion its own address space. however, the history from its real-mode days was that pointer-passing was so ingrained into every area of the environment ... that it couldn't be eradicated. the result was that the 16mbyte address space was initially split with every application 16mbyte virtual address space having 8mbyte kernel image. The problem was further aggravated by subsystems that ran outside of the kernel (in their own application virtual address space) but involved calls by other applications. the hack was something called a 1mbyte "common segment" that also was included in every virtual address space. Towards the late 70s, large installations would have so many subsystems running on the machine ... that it wasn't unusual to find 5mbyte common segments. So now every 16mbyte application virtual address space was occupied by an 8mbyte kernel image and a 5mbyte common segment image ... leaving only 3mbyte available for application.
so the solution introduced on 3033s was "dual-address space" mode. An application could make a supervisor call (passed thru the kernel) for some subsystem operation ... passing an address pointer. The subsystem application running in a different virtual address space ... now could take the passed pointer and reach directly into the virtual address space of the calling program.
this was generalized in the early 80s with access registers introduced with 370-xa (which also introduced 31-bit virtual addressing .. in addition to the 24-bit addressing) to multiple concurrent different virtual address spaces.
370-xa also introduced program call. In addition to extensive convention of pointer passing ... there were large amount of system services that were organized as library code that would run in the application address space and called with branch&link convention. There was an objective to move a lot of the system function library stuff into its own address space(s) .... w/o requiring the overhead of kernel call (to change address space), keeping the efficiency of branch&link. So program call has a special system defined table for specific program calls ... that includes control stuff about which address space and various permission rules (in some ways its analogous to virtual address space tables ... but for program calls instead of addressing). Now applications can make program calls directly into library routines in different address spaces ... using pointer-passing convention. Control is switched to a different address space ... which can take the passed pointers and use them to reach back into the application virtual address space.
So in the early 80s not only were there the issues of 24bit and 31bit addressing ... but also which of a variety of address spaces did the addresses apply to.
this was more recently further confounded with the introduction of 64bit addressing.
some stuff on address spaces
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/3.8?SHELF=DZ9ZBK03&DT=20040504121320
access-register introduction
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/5.7?SHELF=DZ9ZBK03&DT=20040504121320
acdess-register summary
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/5.7.1?SHELF=DZ9ZBK03&DT=20040504121320&CASE=
These major functions are provided:
* A maximum of 16 address spaces, including the instruction space,
for immediate and simultaneous use by a semiprivileged program; the
address spaces are specified by 16 registers called access
registers.
• Instructions for examining and changing the contents of the access
registers.
program call instruction
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/10.34?SHELF=DZ9ZBK03&DT=20040504121320
program return instruction
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/10.35?SHELF=DZ9ZBK03&DT=20040504121320
PC-Number Translation
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/5.5?SHELF=DZ9ZBK03&DT=20040504121320
and discussion of trimodal addressing (24bit, 31bit, & 64bit)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/1.1.5?SHELF=DZ9ZBK03&DT=20040504121320&CASE=
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What ever happened to Tandem and NonStop OS ? Newsgroups: alt.folklore.computers Date: Fri, 30 Sep 2005 13:10:44 -0600echomko_at_@polaris.umuc.edu (Eric Chomko) writes:
IBM and DEC equally funded MIT Project Athena for $25m each ... it
had stuff like X and Kerberos (kerberos widely used authentication
infrastructure ... even windows)
https://www.garlic.com/~lynn/subpubkey.html#kerberos
My wife and I did a couple audit visits to Project Athena during this time (there was one visit when they were just in the process of finalizing design of kerberos cross-domain support).
There was director from MIT and two asst. directors, one from DEC and
one from IBM. For some time, the one from IBM was somebody that had
been at the science center for some time (at the same time I was)
https://www.garlic.com/~lynn/subtopic.html#545tech
he had the distinction of having the compare&swap instruction named
after him (actually he invented it and then the task was to come up
with mnemonic that corresponded to his initials CAS). some collected
postings on smp and/or compare&swap
https://www.garlic.com/~lynn/subtopic.html#smp
IBM's part was somewhat the outgrowth of the ACIS organization ... which started out in the early 80s with $300m it had to give away to educational institutions.
Another place was CMU which was funded to the tune of $50m from IBM ... which brought you things like Andrew widgets, Andrew filesystem, Mach, camelot and some number of other things. Mach was picked up by a number of companies ... including for NeXT which then morphed into the current Apple operating system. Andrew file system was one of the technologies looked at in detail for OSF. There is also the joke that IBM paid for camelot three times, first with the initial CMU funding, second in large investment in TRANSARC (when it was spun off) and 3rd when IBM bought TRANSARC outright.
Another technology was UCLA's locus ... which was a unix compatible(?) system that provided for both heterogeneous distributed operation (both filesystem and execution). Locus was the basis for AIX/370 and AIX/PS2 ... there were some jokes that it was sort of IBM's unix flavor of SAA.
misc .past posts mentioning mach, camelot, locus, and/or project
athena
https://www.garlic.com/~lynn/98.html#35a Drive letters
https://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
https://www.garlic.com/~lynn/99.html#2 IBM S/360
https://www.garlic.com/~lynn/99.html#63 System/1 ?
https://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
https://www.garlic.com/~lynn/2000.html#64 distributed locking patents
https://www.garlic.com/~lynn/2000c.html#8 IBM Linux
https://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs
https://www.garlic.com/~lynn/2000d.html#69 "all-out" vs less aggressive designs
https://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
https://www.garlic.com/~lynn/2001.html#44 Options for Delivering Mainframe Reports to Outside Organizat ions
https://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
https://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
https://www.garlic.com/~lynn/2001b.html#33 John Mashey's greatest hits
https://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
https://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
https://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
https://www.garlic.com/~lynn/2001i.html#49 Withdrawal Announcement 901-218 - No More 'small machines'
https://www.garlic.com/~lynn/2001l.html#17 mainframe question
https://www.garlic.com/~lynn/2001n.html#35 cc SMP
https://www.garlic.com/~lynn/2002b.html#36 windows XP and HAL: The CP/M way still works in 2002
https://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
https://www.garlic.com/~lynn/2002h.html#65 Bettman Archive in Trouble
https://www.garlic.com/~lynn/2002i.html#54 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002i.html#73 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
https://www.garlic.com/~lynn/2002j.html#36 Difference between Unix and Linux?
https://www.garlic.com/~lynn/2002n.html#67 Mainframe Spreadsheets - 1980's History
https://www.garlic.com/~lynn/2002o.html#32 I found the Olsen Quote
https://www.garlic.com/~lynn/2002o.html#40 I found the Olsen Quote
https://www.garlic.com/~lynn/2002p.html#45 Linux paging
https://www.garlic.com/~lynn/2003.html#18 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2003.html#46 Horror stories: high system call overhead
https://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
https://www.garlic.com/~lynn/2003c.html#45 Early attempts at console humor?
https://www.garlic.com/~lynn/2003d.html#2 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#3 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#54 Filesystems
https://www.garlic.com/~lynn/2003e.html#25 A Speculative question
https://www.garlic.com/~lynn/2003e.html#33 A Speculative question
https://www.garlic.com/~lynn/2003h.html#35 UNIX on LINUX on VM/ESA or z/VM
https://www.garlic.com/~lynn/2003h.html#45 Question about Unix "heritage"
https://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
https://www.garlic.com/~lynn/2003h.html#53 Question about Unix "heritage"
https://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"?
https://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
https://www.garlic.com/~lynn/2004d.html#72 ibm mainframe or unix
https://www.garlic.com/~lynn/2004h.html#41 Interesting read about upcoming K9 processors
https://www.garlic.com/~lynn/2004h.html#42 Interesting read about upcoming K9 processors
https://www.garlic.com/~lynn/2004k.html#50 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004l.html#56 project athena & compare and swap
https://www.garlic.com/~lynn/2004n.html#9 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#12 XML: The good, the bad, and the ugly
https://www.garlic.com/~lynn/2004n.html#19 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#20 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
https://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
https://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
https://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
https://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
https://www.garlic.com/~lynn/2005.html#31 Do I need a certificat?
https://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
https://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
https://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#28 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005g.html#49 "Best practices" or "Best implementations"?
https://www.garlic.com/~lynn/2005h.html#5 Single System Image questions
https://www.garlic.com/~lynn/2005i.html#53 Single Password - Linux & Windows
https://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
https://www.garlic.com/~lynn/2005j.html#26 IBM Plugs Big Iron to the College Crowd
https://www.garlic.com/~lynn/2005q.html#14 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/