List of Archived Posts

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

HASP/ASP JES/JES2/JES3
Effective micropayments
Article in Information week: Mainframe Programmers Wanted
winscape?
winscape?
What ever happened to Tandem and NonStop OS ?
What are the latest topic in TCP/IP
HASP/ASP JES/JES2/JES3
What ever happened to Tandem and NonStop OS ?
What ever happened to Tandem and NonStop OS ?
Tapes (3590) and VM
Securing Private Key
What ever happened to Tandem and NonStop OS ?
IPSEC with non-domain Server
What ever happened to Tandem and NonStop OS ?
HASP/ASP JES/JES2/JES3
HASP/ASP JES/JES2/JES3
Ethernet, Aloha and CSMA/CD -
Ethernet, Aloha and CSMA/CD -
HASP/ASP JES/JES2/JES3
Ethernet, Aloha and CSMA/CD -
Ethernet, Aloha and CSMA/CD -
tcp-ip concept
Logon with Digital Siganture (PKI/OCES - or what else they're called)
What ever happened to Tandem and NonStop OS ?
Intel strikes back with a parallel x86 design
What ever happened to Tandem and NonStop OS ?
What ever happened to Tandem and NonStop OS ?
tcp-ip concept
IPSEC wireless router ?
HASP/ASP JES/JES2/JES3
Intel strikes back with a parallel x86 design
HASP/ASP JES/JES2/JES3
Intel strikes back with a parallel x86 design
How To Abandon Microsoft
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Callable Wait State
Intel strikes back with a parallel x86 design
How To Abandon Microsoft
Intel strikes back with a parallel x86 design
Instruction Set Enhancement Idea
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
Intel strikes back with a parallel x86 design
What ever happened to Tandem and NonStop OS ?

HASP/ASP JES/JES2/JES3

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Sun, 18 Sep 2005 11:28:30 -0600
Anne & Lynn Wheeler writes:
another history of hasp & jes2 (share presentation)
http://www.redbug.org/dba/sharerpt/share79/o441.html

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Effective micropayments

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Effective micropayments
Newsgroups: sci.crypt
Date: Sun, 18 Sep 2005 12:02:33 -0600
"Milan VXdgsvt" writes:
Let's imagine the following setup: Alice wants to send many messages to Bob, but she's not connected directly to Bob. Instead she has to transmit messages to Robert the Retransmitter, who sends them to Bob. The trouble is, Robert wants money for this, and does not want to spend too much computation power on this.

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

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

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

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

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

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

and either click on "RADIUS" in the Acronym fastpath or scroll down to
remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058


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

you might also be interest in some of the AAA working group
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3588 3539 3127 2989 2977 2906 2905 2904 2903


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

Article in Information week: Mainframe Programmers Wanted

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Article in Information week: Mainframe Programmers Wanted
Newsgroups: bit.listserv.ibm-main
Date: Mon, 19 Sep 2005 13:09:21 -0600
WM wrote:
I think you're on the right track, John. I've got a kind of half-developed theory that staff that grew up in the mainframe era, where computing resources were extremely expensive and data centers were, actually, awesome, take their work very seriously.

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


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

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

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

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

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

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

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

winscape?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers
Date: Tue, 20 Sep 2005 09:36:23 -0600
Andrew Swallow writes:
That takes 30 years. 20 more to go.

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


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

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

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

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

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

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

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

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

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

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

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

winscape?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: winscape?
Newsgroups: alt.folklore.computers
Date: Tue, 20 Sep 2005 09:46:29 -0600
greymaus writes:
Ordering air tickets last night, finally got to the <credit> stage, one had to click on a box to show you had read the conditions [usual stuff], clicked on conditions highlite, box appeared, nothing in it, I tried this in Firefox, Opera, Netscape, Konqueror, then changed to XP, Opera, IE. I was so mad at this point at the thought that I would have to use a M$ product, that I was relieved when nothing appeared under IE, either. IE, however, sent me on to some M$ site when I mistyped the name. Finally I just clicked on the [Have you read the conditions] radiothingie, and things proceeded. Odd legal point there, if there is a dispute later.

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

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

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

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 20 Sep 2005 12:15:44 -0600
Rick Troth writes:
Very confusing page there. Is it Itanium or MIPS? Is it POSIX or the prior Tandem "Non-Stop OS"?

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

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

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

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

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

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

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

What are the latest topic in TCP/IP

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What are the latest topic in TCP/IP.
Newsgroups: comp.protocols.tcp-ip
Date: Tue, 20 Sep 2005 12:39:57 -0600
"abrar_@yahoo.com" writes:
What are the latest topic in TCP/IP. IS there any ongoing reserach in TCP/IP.Please identify for research papares

try nsf & internet2 project with a search engine.

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

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

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

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

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

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

HASP/ASP JES/JES2/JES3

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Tue, 20 Sep 2005 14:30:00 -0600
Allan Scherr wrote:
The way Spooling was done on the pre-S/360 systems, to my recollection, was with a second computer. The 1410 did I/O for the 7010, for instance. The 1401 was used to to card to tape and tape to printer for larger computers. The first general multiprogramming capabilities that I recall were in some of the IBM special purpose systems in the early 60's like the SABRE airline reservations system or the so called "defense calculator" project that kept track of radar threats. The operating systems I used in the 50's (SOS, FMS, IBYSYS) had no multiprogramming. IBSYS for the 7094 may have picked up this capability near the end of its life in the early 60's, but I didn't use it by then. Anyone remember?

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

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

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

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

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

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

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

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

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Tue, 20 Sep 2005 14:53:26 -0600
Andrew Swallow writes:
Go back to IBM before they unbundled their systems software.

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

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

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

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

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

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

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

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

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Tue, 20 Sep 2005 15:38:50 -0600
"Jack Peacock" writes:
PC's got ethernet as soon as it was affordable, but before ethernet NICs dropped in price PCs were still being connected locally, using ARCnet or less often Token Ring. Now it might have been only about 30% the thruput of ethernet, but ARCnet worked quite well for slower micros in small networks. Netware ran just fine over ARCnet.

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

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


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

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

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

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

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

Tapes (3590) and VM

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tapes (3590) and VM
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 20 Sep 2005 21:51:42 -0600
"Austin, Alyce" writes:
Is it really necessary to shutdown Linux before doing a DDR? I did a DDR and it seem to complete successfully without shutting down Linux. (At least, I didn't get any errors.)

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

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

real time backups of running systems have been done by:

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

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

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

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

Securing Private Key

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing Private Key
Newsgroups: sci.crypt
Date: Wed, 21 Sep 2005 08:33:05 -0600
"Shakeel" writes:
My application make transactions in the database. To make transactions secure or in other words only application can make transactions in DB and not even the DB admin can. For that the application make digital signature with each transaction. Now the problem is for digital signature the key is needed, Hot to secure or manage that key.

from 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor
something you have
something you know
something you are


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

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

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

somewhat more secure is replacing the software/file container with a real physical container ... hardware token with embedded chip. there are a number of them with various combination of integrity characteristics. features can be
1) key pair generated inside the chip, public key exported, but the private key is never divulged.

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

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


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

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

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Wed, 21 Sep 2005 13:05:25 -0600
echomko_at_@polaris.umuc.edu (Eric Chomko) writes:
Didn't IBM have a anti-trust suit started against them back in 1969? Didn't get lifted until after the PC in 1981, ISA, etc.?

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

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

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

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

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

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

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

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

IPSEC with non-domain Server

Refed: **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Newsgroups: microsoft.public.security
Subject: Re: IPSEC with non-domain Server
Date: Thu, 22 Sep 2005 14:41:35 -0700
Steven L Umbach wrote:
If you are using ipsec for just "filtering" then no computer authentication is used anyhow. If you are using it for AH/ESP to authenticate computers and protect traffic integrity and confidentiality then you need to use a computer authentication method. Certificates is the most secure method and any Windows 2000/2003 Server can be a Certificate Authority though trusting your CA may be an issue depending on whether or not you have access to configure those computers that should be allowed access or distribute them the CA's certificate. The problem with pre-shared key is that it is stored on the computers that use it in clear text in the registry and is could be easily recoverable [see link below]. If you do not think that is a problem in your situation then it could be a viable solution and not being in an AD domain is a plus for its use. If you do use be sure to use a complex pre-shared key and change it on a regular basis. --- Steve

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

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

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


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

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

from 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor
something you have
something you know
something you are


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

from the security PAIN acronym
• privacy
• authentication
• integrity
non-repudiation


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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Thu, 22 Sep 2005 18:21:25 -0600
"Rupert Pigott" writes:
OSF/1 was renamed Digital Unix, which in turn was renamed to Tru64 (a typically tacky touch from Compaq). I mostly used it when they called it Digital Unix. I saw more DU boxes out there than VMS boxes in the mid-late 90s.

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


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

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

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

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

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

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

HASP/ASP JES/JES2/JES3

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Date: Thu, 22 Sep 2005 18:07:25 -0600
Newsgroups: bit.listserv.ibm-main
Skip Robinson wrote:
My favorite is still ISPF. It's predecessor, SPF, expressly stood for Structured Programming Facility. Not content merely to add Interactive, the Hot Button Brigade (tech savvy cousins of the Political Correctness Police) also re-engineered 'SP' to System Productivity.

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

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

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

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

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

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

HASP/ASP JES/JES2/JES3

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Date: Thu, 22 Sep 2005 18:32:44 -0600
Newsgroups: bit.listserv.ibm-main
and of course in the interest of political correctness when cp67 morphed into vm370 .... the cambridge monitor system (cms) was reborn as the conversational monitor system.

Ethernet, Aloha and CSMA/CD -

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet, Aloha and CSMA/CD -
Newsgroups: comp.arch.embedded,alt.folklore.computers
Date: Fri, 23 Sep 2005 10:06:11 -0600
Roberto Waltman writes:
May be, but it also may have been an unavoidable mistake - I can not think of a better approach for Hawaii's original ALOHA radio network on which Ethernet/CSMA/CD where partially based. (Especially when you consider the technology available at the time.)

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


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

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

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

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

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

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

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

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

Ethernet, Aloha and CSMA/CD -

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet, Aloha and CSMA/CD -
Newsgroups: comp.arch.embedded,alt.folklore.computers
Date: Fri, 23 Sep 2005 10:30:43 -0600
"Tim Shoppa" writes:
The token ring advocates always pointed out how certain circumstances could lead to collision detection not working nicely. They were also extremely unconfortable with the lack of guaranteed bandwidth for each master etc.

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


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

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

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

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

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

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

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

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

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

HASP/ASP JES/JES2/JES3

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Newsgroups: bit.listserv.ibm-main
Date: Fri, 23 Sep 2005 10:56:10 -0600
JO.Skip.Robinson@ibm-main.lst wrote:
At the opposite extreme we have TSO, which as far as I know still stands for 'Time Sharing Option' but has not shared time or been optional for decades. I guess that's how you know when you're no longer strategic: nobody bothers to rebirth your obsolete acronym. ;-(

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

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

Ethernet, Aloha and CSMA/CD -

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet, Aloha and CSMA/CD -
Newsgroups: comp.arch.embedded,alt.folklore.computers
Date: Fri, 23 Sep 2005 13:10:07 -0600
ref:
http://www.garlic.com/~lynn/2005q.html#17 Ethernet, Aloha and CSMA/CD
http://www.garlic.com/~lynn/2005q.html#18 Ethernet, Aloha and CSMA/CD

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

overflowed into a number of areas.

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

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

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

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

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

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

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

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

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

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

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

Ethernet, Aloha and CSMA/CD -

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ethernet, Aloha and CSMA/CD -
Newsgroups: comp.arch.embedded,alt.folklore.computers
Date: Fri, 23 Sep 2005 13:43:55 -0600
Anne & Lynn Wheeler writes:
in this period, a new generation of hub/spoke enet cards were appearing (with new generation of enet controller chips like the 16bit amd lance), where each card was capable of sustaining full 10mbit (aka a server could transmit 10mbit/secs serving a client base having aggregate 10mbit/sec requirements).

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

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

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

tcp-ip concept

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: tcp-ip concept
Newsgroups: comp.protocols.tcp-ip
Date: Sat, 24 Sep 2005 11:46:04 -0600
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
The two directions are not independant. TCP in one direction will only send as much data as will fill the negotiated window size; after that, it needs an ACK from the other end before it sends more. That ACK is a "response". The ACK need not be accompanied by any meaningful data, but it is still a response.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


One of the issues has been confusing identification and authentication.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

something you have
something you know
something you are

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

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sat, 24 Sep 2005 16:02:04 -0600
jmfbahciv writes:
His dream had always been to make a new (and I mean new) OS. He had extensive experience in what not to do w.r.t. memory management, interrupt handling, virtual memory, etc. He knew the pluses and minuses of TOPS-10, TOPS-20, VMS, and two flavors of Unix, one intimately. With all that OS background, turning him and a few others loose on an R&D project would have been profitable and useful. When given the job of OS/1 (in the beginning) he somehow got the impression that this new design was the goal. It was not; the design had to be Unixy. I never understood putting that constraint on the project.

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

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

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

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

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

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

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

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sat, 24 Sep 2005 19:02:29 -0600
Jim Brooks writes:
My speculation is that Intel will build on their HyperThread experience to design a "parallel x86". x86 CPUs have become superscalar machines. The next evolutionary step is a parallel machine. Dual-cores are only an inefficient stop-gap design that wastes transistors with duplicated or unnecessary resources (eg coherency logic between the core's caches).

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

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

how 'bout ncube:
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 there were so many people tied up in working on such stuff that one such new mpp project ... looking around for people to lead the effort, got around to asking my wife and me. I ran thru all the names I could think of them to ask (before us) ... and they pointed out that everybody I suggested, were all busy, tied up on something else

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 25 Sep 2005 09:25:05 -0600
"Rupert Pigott" writes:
Amdahl released "UTS", a UNIX that ran under VM on their IBM mainframe clones (they produced very big fast machines). Also Cray shipped a UNIX called "UNICOS" with their supercomputers.

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

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

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

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 25 Sep 2005 10:37:24 -0600
jmfbahciv writes:
Yea. That was a pesky problem and I don't think we (DEC) knew enough about it. Would IBM have had a better idea since they knew how to do serious batch? I wasn't clear to me that distributed computing was the same as distributed processing (I don't think I wrote this clearly).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tcp-ip concept

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: tcp-ip concept
Newsgroups: comp.protocols.tcp-ip
Date: Sun, 25 Sep 2005 10:55:52 -0600
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
The first sentance of the OP question asked about sending "continuous packets" "without waiting for a response".

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


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

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

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

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

IPSEC wireless router ?

From: lynn@garlic.com
Subject: Re: IPSEC wireless router ?
Date: Sun, 25 Sep 2005 12:33:53 -0700
Newsgroups: alt.internet.wireless
David Taylor wrote:
It's not new Duane. All you're doing is blocking traffic by port. I'm surprised that it's new to you.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HASP/ASP JES/JES2/JES3

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: HASP/ASP JES/JES2/JES3
Date: Sun, 25 Sep 2005 20:49:51 -0600
Newsgroups: bit.listserv.ibm-main
Ed Gould wrote:
I think you are correct. SPF was developed here in Chicago at a ladies undergarment maker. My mind is sketchy though whether it was written by an IBM se or it could have been a joint effort. I remember our SE trying to sell it to us. but we were out of gas, CPU wise and we settled for FSE. I mean we were *REALLY* out of gas on our 168MP. Our paging rate was out of sight as well. Memory in those days (IIRC) was $10K (US) a meg and we just couldn't afford any more.

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

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

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


370s were limited to 24bit real & 24bit virtual addressing. two processor smp machines could be cleaved in half and operated as two independent machines (but two processor smp configuration was still limited to 16mbyte real)

370/158 had integrated channels ... the microcode engine was shared between 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 ONLY

misc. past posts that mention 4341 and 3033
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002b.html#2 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#59 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002p.html#59 AMP vs SMP
http://www.garlic.com/~lynn/2002q.html#27 Beyond 8+3
http://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003f.html#50 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003l.html#31 IBM Manuals from the 1940's and 1950's
http://www.garlic.com/~lynn/2004.html#7 Dyadic
http://www.garlic.com/~lynn/2004.html#8 virtual-machine theory
http://www.garlic.com/~lynn/2004d.html#12 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Re: Vintage computers are better
http://www.garlic.com/~lynn/2004l.html#10 Complex Instructions
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
http://www.garlic.com/~lynn/2004n.html#14 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#29 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2005p.html#19 address space

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **
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:
The iapx432 being designed by a bunch of Phds with no clue about hardware costs never reached the market AFAIR and the 8086 backup plan went into effect. Eventually Intel must have forgot that lesson.

the last asilomar acm sigops (before they starting letting the conference wander around, there was midnight session bemoaning that the pennyless mit students always had to pay for coast-to-coast trip, and it would only be fair if the berkeley students should sometimes have to pay coast-to-coast fare for sigops conferences) ... there was presentation on iapx432 effectively moving some number of operating system features into silicon ... features that have had a somewhat significant change rate ... and the requirement for change didn't stop when the features were in silicon (but iapx432 silicon was lacking in ability to make such changes).

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

HASP/ASP JES/JES2/JES3

Refed: **, - **, - **, - **
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 -0600
Ed Gould wrote:
I don't recall the name of the (I think a Swedish developed program) that was similar to Wylbur, but there is a large user of that still here in Chicago. They are really stuck in the 60's they love the product . They have some trouble try to recruit sysprogs to work on the beast. I ran from the interview room (not literally ) .. now I remember its called MUSIC . They have so much code (of their own) in it they really have a "fun" time with new DASD. Chuckle.

can you say mcgill university
http://www.answers.com/topic/music-sp

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **
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:
Which market exactly was the 386 going to cannibalize? The 286 market?

there was period (fall '88) where far east clone manufacturers built up an enormous inventory of 286 systems in preparation for fall season buying frenzy ... and cut-rate 386sx systems come on the market and wiped out the 286 demand. all those 286 systems eventually flooded the market at fire sales.

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

How To Abandon Microsoft

Refed: **, - **, - **, - **, - **
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 -0600
Mxsmanic writes:
Being lean does not make an OS secure, although it often makes it easier to _verify_ that an OS is securely _configured_.

For example, in UNIX, if a server is being used for a few specific purposes, it's usually easy to figure out exactly what openings there are into the machine from the network, and secure them. Windows has a lot of undocumented network openings that must be found and closed to lock down the machine.


succinct & KISS may not only make it easier to verify but also contribute to higher integrity implementations.

as an undergraudate, 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).
http://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
http://www.garlic.com/~lynn/submain.html#unbundle

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **
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 -0600
on 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%

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
archmage@sfchat.org (Nate Edel) writes:
Good heavens, it really is that old (released in 1983!) ... though as I recalled, the first version ran on a proprietary box (68k based, according to Wikipedia:
https://en.wikipedia.org/wiki/Novell_Netware
and not on a standard PC.


there was this DataHub project started around summer of '81 that had a work-for-hire contract with a bunch of people in provo (for a time, one of the people in san jose was commuting almost weekly to provo).

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

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

Callable Wait State

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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-main
Charles Mills wrote:
You could write a subroutine to loop for one CPU second. That would fulfill the letter of the request below. Looping was how one implemented delays on single-processing small computers.

It would not be a career-enhancing technique to use under z/OS.


but it was one of the common things way back when ... especially with lots of the polling stuff. it would really hit badly when you migrated a single application processing environment into a virtual machine guest. there were all sorts of hacks developed to try and apply processing loop compensation. another looping scenario that use to be quite prevalent were things TIO-loops on SM+BUSY status ... that preiodically would run away.

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
http://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

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

one of the issues was that we weren't allowed to bid on the original NSFNET backbone
http://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
http://www.garlic.com/~lynn/2002k.html#12 NSFNET Program Announcement
http://www.garlic.com/~lynn/2000e.html#10 NSFNET Award Announcement<

random past postings mentioning rate-based pacing:
http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
http://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful amachine was it?
http://www.garlic.com/~lynn/2002k.html#56 Moore law
http://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
http://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
http://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
http://www.garlic.com/~lynn/2003j.html#46 Fast TCP
http://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
http://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
http://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
http://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
http://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#3 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Joe Seigh writes:
That's entirely possible. Lots of midrange offering got canceled or crippled because they competed with the low end of the mainframe lines. The RT (early powerpc) systems were rumored to be crippled to make them fit into IBM's product line price/performance curve. IBM couldn't have cheaper machines outperforming more expensive machines.

fort knox was going to convert all the large number of different corporate microprocessors & microengines to 801s. the 4341 follow-on was going to be an 801 based microprocesser; there was a brand new building built in endicott just for the group.

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
http://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)
http://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
http://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:
http://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
http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3

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

How To Abandon Microsoft

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 -0600
Bryan Olson writes:
Unix was practically a rebellion against Multics; they are radically different systems. The work that Mxsmanic so ignorantly describes as a "hobbled imitation" won the highest award in computer science, the ACM Turing Award.

https://en.wikipedia.org/wiki/Turing_Award

(Incidentally, the leader in developing Multics also won an ACM Turing Award.)


multics was done 5th floor 545 tech sq

much of the virtualization work from the 60s, referenced in the previous post
http://www.garlic.com/~lynn/2005q.html#34 How To Abandon Microsoft

was done on the 4th floor 545 tech sq
http://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)
http://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 mutlics 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 | http://www.garlic.com/~lynn/

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
Tony Hill writes:
By 1989 (2 years before IBM delivered PowerPC), x86 was FIRMLY entrenched in the software market.

more like 2 years before starting somerset and the design of power/pc

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
http://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 scaleup.

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

Instruction Set Enhancement Idea

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0700
Edward E. Jaffe wrote:
That's a good question. Right now PSW keys 10-15 are (almost?) never used for anything. Key 9 is used slightly in a somewhat kludgy manner.

DOS/VS aka VSE/ESA aka z/VSE gives each "static" partition its own storage key. This harkens back to the real-memory-only days when there was one -- and only one -- address space. That's pretty much just old baggage any more since the advent of dynamic partitions, which look a whole lot like MVS address spaces.


MVS wasn't exactly immune from its real-memory-only, single address space heritage.

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.

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips
Date: Thu, 29 Sep 2005 10:24:44 -0600
Del Cecchi writes:
Romp and rios were two different things as I recall. Although they say memory is second thing to go. As for Romp, what do you expect from a processor designed in Yorktown. :-)

romp was 16bit processor that was supposed to be for the displaywriter follow-on ... it was only after the project got killed ... that somebody noticed that you could port unix to any chip and call it a unix workstation ... previous post
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back wtih a parallel x86 design

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.ibm.pc.hardware.chips
Date: Thu, 29 Sep 2005 11:43:14 -0600
Del Cecchi writes:
Romp and rios were two different things as I recall. Although they say memory is second thing to go. As for Romp, what do you expect from a processor designed in Yorktown. :-)

talk about fading memory ... and needing to dig something out of the archives ... there is this nagging in the back of my mind about the ibm 386 ... something about yields or something at intel (and meeting demand) and ibm was going to fab some ... but ibm couldn't resist tweaking the design. does anybody have recollection of what the chip was called?

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **
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 -0600
as 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
http://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

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **
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 -0600
and 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

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
A question for all you omniscient ones out there - what were the worst computers of all time? IBM's candidate must surely be the PC/RT, but A,T&T are strong competitors with the 3B2.

i wouldn't consider it even close to the 8100.

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 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
http://www.garlic.com/~lynn/2002k.html#12 ... nsfnet backbone RFP announce
http://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
http://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 | http://www.garlic.com/~lynn/

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **
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 -0600
ref:
http://www.garlic.com/~lynn/2005q.html#46

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

Intel strikes back with a parallel x86 design

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
To the best of my knowledge, the only system that has attempted to support mixed addressing modes within a single executable has been IBM, on its System/370 line. Now, that WAS tricky!

addressing gets a lot more tricky than 24-bit, 31-bit, and now, 64-bit addressing.

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

What ever happened to Tandem and NonStop OS ?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0600
echomko_at_@polaris.umuc.edu (Eric Chomko) writes:
Didn't MIT actually fund the X project? DEC was handy hardware. I think you given them too much credit. Besides X-Window has a HUGE footprint, very un-UNIX-like, more like Windows (gasp!). Sorry, you can have it. I prefer Tcl/Tk or Perl/tk these days.

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)
http://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)
http://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
http://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
http://www.garlic.com/~lynn/98.html#35a Drive letters
http://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
http://www.garlic.com/~lynn/99.html#2 IBM S/360
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000d.html#68 "all-out" vs less aggressive designs
http://www.garlic.com/~lynn/2000d.html#69 "all-out" vs less aggressive designs
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
http://www.garlic.com/~lynn/2001.html#44 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
http://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
http://www.garlic.com/~lynn/2001b.html#33 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001i.html#49 Withdrawal Announcement 901-218 - No More 'small machines'
http://www.garlic.com/~lynn/2001l.html#17 mainframe question
http://www.garlic.com/~lynn/2001n.html#35 cc SMP
http://www.garlic.com/~lynn/2002b.html#36 windows XP and HAL: The CP/M way still works in 2002
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002h.html#65 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#54 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002i.html#73 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002j.html#36 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002n.html#67 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002o.html#32 I found the Olsen Quote
http://www.garlic.com/~lynn/2002o.html#40 I found the Olsen Quote
http://www.garlic.com/~lynn/2002p.html#45 Linux paging
http://www.garlic.com/~lynn/2003.html#18 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003.html#46 Horror stories: high system call overhead
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
http://www.garlic.com/~lynn/2003c.html#45 Early attempts at console humor?
http://www.garlic.com/~lynn/2003d.html#2 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#3 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#54 Filesystems
http://www.garlic.com/~lynn/2003e.html#25 A Speculative question
http://www.garlic.com/~lynn/2003e.html#33 A Speculative question
http://www.garlic.com/~lynn/2003h.html#35 UNIX on LINUX on VM/ESA or z/VM
http://www.garlic.com/~lynn/2003h.html#45 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003h.html#53 Question about Unix "heritage"
http://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"?
http://www.garlic.com/~lynn/2004c.html#53 defination of terms: "Application Server" vs. "Transaction Server"
http://www.garlic.com/~lynn/2004d.html#72 ibm mainframe or unix
http://www.garlic.com/~lynn/2004h.html#41 Interesting read about upcoming K9 processors
http://www.garlic.com/~lynn/2004h.html#42 Interesting read about upcoming K9 processors
http://www.garlic.com/~lynn/2004k.html#50 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#56 project athena & compare and swap
http://www.garlic.com/~lynn/2004n.html#9 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#12 XML: The good, the bad, and the ugly
http://www.garlic.com/~lynn/2004n.html#19 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#20 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://www.garlic.com/~lynn/2004n.html#38 RS/6000 in Sysplex Environment
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2005.html#31 Do I need a certificat?
http://www.garlic.com/~lynn/2005b.html#1 Foreign key in Oracle Sql
http://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
http://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#28 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005g.html#49 "Best practices" or "Best implementations"?
http://www.garlic.com/~lynn/2005h.html#5 Single System Image questions
http://www.garlic.com/~lynn/2005i.html#53 Single Password - Linux & Windows
http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005j.html#26 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005q.html#14 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?

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


previous, next, index - home