From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 22 Jun 2007 14:03:05 -0600 Frank McCoy <mccoyf@millcomm.com> writes: BULL. There was far more software available on CP/M at the time than IBM ever provided. OTHER companies soon started supplying, once the market was there; but not when the PC came out. No, the reason was corporate "standards" as explained above. http://www.garlic.com/~lynn/2007m.html#50 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM and/or corporate marketing ... majority of the people in the period ... didn't understand what personal computing and/or PC software actually met ... marketing such abstractions would have little meaning (sufficient understanding of how they might actually benefit). 3270 terminals to the mainframe did have some meaning ... and terminal emulation, effectively same price, same footprint ... with the addition of something more than 3270 terminal emulation ... even if the vast majority of people had no idea what that actually added value really met (but it wasn't a risk/justification issue ... the cost/justification was covered by its play as added value 3270 terminal replacement). it didn't have to be a "standard" as something officially proclaimed ... although it could be an implicit standard ... in that terminal emulation was something that the vast majority of the people could relate to and believe they could understand. this previous post http://www.garlic.com/~lynn/2007m.html#63 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM with this reference on personal computer market share, 1975-2004: http://www.wowdailynews.com/pegasus/total_share.html shows TRS-80 with the earliest annual volumes of few hundred thousand ... then later atari 400/800, and eventually the apple II in the 80s. the closest to the pc in volumes was the commodore 64 in 83/84 with millions ... but they weren't selling into the terminal emulation market ... and that really shifted by 85/86 (commodore 64 stayed in there with 2.5m/annum in 84, 85, & 86 ... while the pc+clones continued to significantly increase).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 22 Jun 2007 15:34:00 -0600 Morten Reistad <first@last.name> writes: 2.6 came out in 2005 after a 5-year wait, and delivered on promise. Linux 2.6 was just such a painful redesign, and IBM has contributed a lot to that code. There are still corners in the code that only do SMP moderatly well, but they are mostly backwards-compatible areas. and at least some of that is purported to have been stuff from sequent (dynix and numa-q), i.e. after ibm bought sequent. back before numa-q ... when sequent was running both dynix and nt on their i86 (32-way) SMPs ... they had claimed that much of the smp scaleup in NT had come from work they had done ... aka previous posts with some number of wiki & other refs: http://www.garlic.com/~lynn/2007m.html#13 Is Parallel Programming Just Too Hard? random other recent posts mentioning sequent &/or numa-q http://www.garlic.com/~lynn/2007m.html#8 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007m.html#27 nouns and adjectives http://www.garlic.com/~lynn/2007m.html#72 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM and for other topic drift, old posts mentioning that steve chen shows up as sequent's CTO in the 90s (we had done a little consulting for him at sequent) http://www.garlic.com/~lynn/2002h.html#42 Looking for Software/Documentation for an Opus 32032 Card http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out http://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article? http://www.garlic.com/~lynn/2006y.html#38 Wanted: info on old Unisys boxen
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: One OS for everybody .... Newsgroups: alt.folklore.computers Date: Fri, 22 Jun 2007 15:56:55 -0600 jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes: I just wish I knew about modular exponentiation back when I was a wee lad and saw that movie for the first time. Who knows, it might have inspired me to invent RSA before anyone else... a few old emails on subject of crypto and/or public key from 70s & 80s http://www.garlic.com/~lynn/lhwemail.html#crypto and couple more recent posts about working on a really inexpensive, really fancy crypto hardware (in the mid-80s) http://www.garlic.com/~lynn/2006n.html#36 The very first text editor http://www.garlic.com/~lynn/2006u.html#45 waiting for acknowledgements
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 22 Jun 2007 16:57:23 -0600 Morten Reistad <first@last.name> writes: I hold dimetrically opposite views of the 80s. That was when all the dispersed efforts came together. *n*x came of age, took up a lot of the practices from other fields, and became a workhorse. RISC came out of the closet. RAID was invented. Networking came to it's own. The Open Source movement got going. The monopoly power of the vendors was crushed, and the customer came in charge. Software was unbundled from hardware. note that the 23jun69 unbundling announcement met that software was charged separately from the hardware. prior to that the software had been free. http://www.garlic.com/~lynn/submain.html#unbundle this was result of various litigation. however, they did make the case that kernel software was necessary for the hardware operation ... and therefor should still be free. later, the rise of the processor clones gave them reason to rethink the decision. I was getting ready to (re)release the resource manager (after much of it having been dropped in the morph from cp67 and vm370) ... and it was selected to be the guinea pig for starting to charge for kernel software. http://www.garlic.com/~lynn/subtopic.html#fairshare http://www.garlic.com/~lynn/subtopic.html#wsclock in effect, prior to the litigation and the unbundling announcement, software was free and (much of it,) open source. an example was the large share/waterloo (, univerisity of) software libraries for cp67, vm370, cms, etc ... including source updates/enhancements (i.e. cp67, vm370, cms, etc not only was shipped as source ... but the monthly updates/fixes were also shipped as source). Standard procedure at many customers was to build/generate system from the source. first patent for disk array, san jose plant site, '78: http://www.garlic.com/~lynn/2002e.html#4 Mainframers: Take back the light (spotlight, that is) http://www.garlic.com/~lynn/2004d.html#29 cheaper low quality drives http://www.garlic.com/~lynn/2006p.html#47 "25th Anniversary of the Personal Computer" later IBM "co-sponsored research at UCB" that led to the raid level definitions in '87 ... but i believe that first deployed use was by as/400.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: the Depression WWII Newsgroups: alt.folklore.computers Date: Sat, 23 Jun 2007 07:47:31 -0600 Steve O'Hara-Smith <steveo@eircom.net> writes: Ugh when you put it that way it's a wonder anything works given that the bureaucracies full of middle managers seem to turn up in every system. or boyd's scenario about doing something or taking credit for doing something ... from dedication of Boyd Hall at USAF weapons school: http://www.garlic.com/~lynn/2007.html#20 MS to world: Stop sending money, we have enough - was Re: Most ... can't run Vista http://www.garlic.com/~lynn/2007h.html#74 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007j.html#61 Lean and Mean: 150,000 U.S. layoffs for IBM? http://www.garlic.com/~lynn/2007j.html#77 IBM Unionization http://www.garlic.com/~lynn/2007k.html#3 IBM Unionization http://www.garlic.com/~lynn/2007k.html#5 IBM Unionization
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 23 Jun 2007 07:52:49 -0600 Steve O'Hara-Smith <steveo@eircom.net> writes: The defense against these is simple - ignore them and never connect to a bank except via SSL to a known starting point - note that it is important to start in SSL so that no transparent proxy can intervene. recent thread/post you may find of interest: http://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure network protocol http://www.garlic.com/~lynn/aadsm27.htm#30 A secure Internet requires a secure network protocol on following subject A secure Internet requires a secure network protocol http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html from above: Implementing -- and requiring -- stronger authentication and cryptography standards is the next step toward a new Internet ... snip ... i.e. a new internet is required ... along with new authentication and crypto standards
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 23 Jun 2007 08:10:55 -0600 Morten Reistad <first@last.name> writes: Also, log structured file systems, the jfs and contributions to efs3, and huge improvements to the irq and dma routing; including some work in processor affinities. metadata logging is slightly different from log structured file systems. one of the problems with log structured file systems is the periodic "garbage collection" done to consolidate files, making their records sequential and contiguous. for other drift ... during work on HA/CMP http://www.garlic.com/~lynn/subtopic.html#hacmp we hired one of the people responsible for doing the BSD log structured filesystem implementation to consult on doing a "geographically distributed filesystem". JFS was originally done by people working on 801/AIXV3. 801 early on had definition/implementation for "database memory" ... i.e. hardware could keep track of fine-grain changes (size on the order of cache-lines). Just load up data into memory mapped infrastructure ... provide the COMMIT boundaries ... and eliminate needing to sprinkle "log" calls thruout the code. At commit, just run thru the changed memory indications ... collecting data-lines needing logging. There had been various kinds of conflict between the unix development group in palo alto and the group in austin. The palo alto group took JFS and ported it to non-801 platforms ... having to retrofit the logging calls to the software (since they lacked database memory hardware). It turns out that the version with explicit logging calls ran faster than the original implementation (even on the same 801 hardware platform) ... the commit time scanning of memory for changes tended to be higher overhead than the explicit log calls. Then the remaining justification for database memory is the implementation simplification ... somewhat akin to some of the pushes for parallel programming (except parallel programming is frequently explicitly about performance; not trying to trade-off performance against simplicity). some of the database memory stuff can be found under the heading of transactional memory ... some posts mentioning transactional memory: http://www.garlic.com/~lynn/2005r.html#27 transactional memory question http://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal of R&D http://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism? misc. past posts mentioning log structured filesystems http://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice http://www.garlic.com/~lynn/93.html#29 Log Structured filesystems -- think twice http://www.garlic.com/~lynn/2000c.html#24 Hard disks, one year ago today http://www.garlic.com/~lynn/2001f.html#59 JFSes: are they really needed? http://www.garlic.com/~lynn/2002b.html#20 index searching http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer http://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill http://www.garlic.com/~lynn/2004g.html#22 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2005l.html#41 25% Pageds utilization on 3390-09? http://www.garlic.com/~lynn/2005n.html#36 Code density and performance? http://www.garlic.com/~lynn/2006j.html#3 virtual memory http://www.garlic.com/~lynn/2006j.html#10 The Chant of the Trolloc Hordes http://www.garlic.com/~lynn/2007.html#30 V2X2 vs. Shark (SnapShot v. FlashCopy) http://www.garlic.com/~lynn/2007i.html#27 John W. Backus, 82, Fortran developer, dies some past posts mentioning database memory http://www.garlic.com/~lynn/2002b.html#33 Does it support "Journaling"? http://www.garlic.com/~lynn/2002b.html#34 Does it support "Journaling"? http://www.garlic.com/~lynn/2003c.html#49 Filesystems http://www.garlic.com/~lynn/2003d.html#54 Filesystems http://www.garlic.com/~lynn/2005n.html#20 Why? (Was: US Military Dead during Iraq War http://www.garlic.com/~lynn/2005n.html#32 Why? (Was: US Military Dead during Iraq War http://www.garlic.com/~lynn/2006o.html#26 Cache-Size vs Performance http://www.garlic.com/~lynn/2006y.html#36 Multiple mappings http://www.garlic.com/~lynn/2007i.html#27 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What if there were two Internets? Newsgroups: soc.history.what-if,alt.history.what-if,alt.folklore.computers,alt.fan.cecil-adams Date: Sat, 23 Jun 2007 08:19:57 -0600 "Dave Wade" <g8mqw@yahoo.com> writes: Certainly in Europe we had two "internets" that reflect the above. We had the public X.25 network including the JANET X.25 academic network, which many thought of as the BETA version. After all it had end-to-end flow control, guaranteed packet delivery, quality of service that was implemented from day. On top of that we had software that conformed to formal standards, and which was fully tested.... The big problem with it was that it was controlled by the PTTs whose charging model was to wring every cent they could out of it. So there were call costs to connect, plus a connection time on the "PAD", and on top of that a charge per packet. I know there wasn't any WEB but there was e-mail, file transfer, and job transfer. But its now long gone.... Pity there aren't copies of the standards on the BITSAVERS web sites..... re: http://www.garlic.com/~lynn/2007m.html#71 What if there were two Internets? EARN was the european version of BITNET ... misc. past posts about BITNET &/or EARN http://www.garlic.com/~lynn/subnetwork.html#bitnet a couple old emails with the person charged with setting up EARN: http://www.garlic.com/~lynn/2001h.html#email840320 http://www.garlic.com/~lynn/2006w.html#email850607
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: nouns and adjectives Newsgroups: alt.folklore.computers Date: Sat, 23 Jun 2007 09:37:32 -0600 jmfbahciv writes: Nobody seems to be getting this. Lynn sees a little bit of the problem but not the work, bit and human flows all together...I think. actually we've had to do the whole thing several times ... the issue is actually getting them all addressed/implemented in an end-to-end manner. the whole set of postings about "naked" transactions is somewhat related to some of the end-to-end issues http://www.garlic.com/~lynn/subintegrity.html#payment and recent references to how SSL is now actually operating (from an end-to-end human perspective) ... as opposed to how it was originally designed to operation (again from human perspective). http://www.garlic.com/~lynn/2007n.html#5 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure network protocol http://www.garlic.com/~lynn/aadsm27.htm#30 A secure Internet requires a secure network protocol changing existing infrastructure is hard. when we were doing our (internal) backbone, we were not allowed to bid on nsfnet backbone ... even tho there was an nsf audit that said what we had already running was at least five yrs ahead of all (nsfnet rfp) bids to build something new ... now some of the stuff looks like it will show up in "internet2" ... which makes it 20+ yrs ... not five. another scenario is all the AADS work in the 90s http://www.garlic.com/~lynn/x959.html#aads part of it includes reducing the cost of a widely deployed, high integrity, hardware token authentication infrastructure by potentially four orders of magnitude (two orders of magnitude in the per token cost and possibly another two orders of magnitude in the number of such tokens that would be required). even a single order of magnitude change in costs is likely to face strong opposition by somebody. lots of infrastructures become succesful because there is somebody with strong financial motivation pushing them. an infrastructure that purely saves everybody oodles of money may have lots of problems because it would lack individuals with strong financial motivation to see it succeed, and potentially also facing strong opposition from those that had interests in maintaining the existing status quo. another example, somewhat alluded to in recent threads ... is translating NSFNET backbone infrastructure to commercial environment. Lots of the telco community had strong interest in having the NSFNET infrastructure succeed as a technology incubator (for new generation of bandwidth hungry applications). However, at the same time, the internetworking model applied to traditional, commercial telco business would have severe disruption on their traditional revenue streams. this would create enormous ambivalence in those businesses ... frequently, strongly backing NSFNET as a "research only" incubator environment ... and at the same time, strongly opposing having the internetworking model break-out into the commercial world). http://www.garlic.com/~lynn/2007m.html#71 What if there were two Internets? http://www.garlic.com/~lynn/2007n.html#7 What if there were two Internets? we've periodically have advised people (that have called us in to consult), to be careful of what you ask for. in a case where we were called in by one of the large airline res systems to look at the "ten impossible things" they couldn't do. After a week or two study ... we went away for two months and then came back with a complete replacement implementation, that would do all of their "ten impossible things" (as well as all the stuff they were currently doing). This was met with quite a bit of dismay and anguish. One way of describing the core problem was that they had something like 800 people involved in doing various kinds of tasks .. and it would be necessary to automate all those tasks in order to succesfully address the "ten impossible things". Any elimination of 800 positions would propagate up the whole organization chain ... impacting the "importance" (and presumably compensation) of the upper level executives. Eventually, they would pretend like the whole sequence had never occured.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: John W. Backus, 82, Fortran developer, dies Newsgroups: alt.folklore.computers Date: Sat, 23 Jun 2007 09:57:35 -0600 Steve O'Hara-Smith <steveo@eircom.net> writes: SSL is strong encryption and *very* hard to break. From a FAQ: Q: How secure is the encryption used by SSL? A: It would take significantly longer than the age of the universe to crack a 128-bit key. Of course if someone finds a way to do it other than brute forcing all 2^128 possible keys then things get a little sticky. Equally of course if you put a large network (say every Windows machine you can work into) onto the job it would be quicker, you might even finish before the sun goes out. SSL was supposed to be two things: 1) is the webserver that you think you are talking to, actually the webserver that you are talking to (aka authentication) 2) encryption to hide transmitted information ... previous reference, I point out that because of certain assumptions about human behavior interacting with browsers ... which are no longer valid assumptions (or at least rarely so) ... and therefor can be leveraged by attackers: http://www.garlic.com/~lynn/2007m.html#27 nouns and ajectives http://www.garlic.com/~lynn/2007n.html#5 John W. Backus, 82, Fortran developer, dies to defeat assumptions about whether the user is talking to the webserver that they think they are talking to. one of the major world-wide SSL uses for information "hiding" is in electronic-commerce for hiding credit card numbers. the issue is that information from previous/existing transactions can relatively trivially used by crooks in fraudulent financial transactions (primarily because of relatively weak authentication in other parts of the infrastructure). the observation was that the majority of data-breach and security-breach compromises in this area, hasn't been from evesdropping on internet (even before ssl) but from all sorts of compromises at the end-points ... lots and lots of mechanisms used by crooks to harvest such information http://www.garlic.com/~lynn/subintegrity.html#harvest little, if any, addressed by SSL internet transmitted information hiding. we had been called in by small client/server startup that wanted to do payment transactions (i.e. electronic commerce) on their servers, and they had this technology they called SSL that they wanted to use. http://www.garlic.com/~lynn/subnetwork.html#gateway after doing that, we got involved in the x9a10 financial working group, that in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. http://www.garlic.com/~lynn/x959.html#x959 this involved a detailed, end-to-end study of threats and vulnerabilities ... including, but not limited to transmission of payment transactions over the internet. the result was using digital signatures to effectively armor every x9.59 transaction (strong authencation as well as strong integrity) and a business rule that information from x9.59 transactions could not be used in non-x9.59 transactions. X9.59 financial standard eliminated evesdropping, havesting, skimming, data breaches, and other kinds of exploits related to crooks using gathered information for being able to generate fraudulent transactions (not just limited to transactions transmitted over the internet). As a result, X9.59 also eliminated the need for the prevailing use of SSL in the world today (hiding information that would be useful to crooks). this is also somewhat discussed in the naked payment/transaction collection of posts http://www.garlic.com/~lynn/subintegrity.html#payments
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The top 10 dead (or dying) computer skills Newsgroups: alt.folklore.computers Date: Sat, 23 Jun 2007 12:28:09 -0600 John Ahlstrom <AhlstromJK@comcast.net> writes: As a former boss always said: Demo costs 1 unit Usable by others 10 units stand alone product 100 units Integrated into a system 1000 units Course that was a long time ago. I wonder what the relative figures are now. we've used the number of 4-10 times to take a thuroughly checked-out and debugged application and turn it into a "service". in the case of the payment gateway ... for the stuff that has since come to be called "electronic commerce" ... it was around 10 times http://www.garlic.com/~lynn/subnetwork.html#gateway a lot of the effort isn't directly code ... but detailed understanding of how things might fail ... and to be able to recover (and/or at least diagnose) such failures. a somewhat related comment about ports of UNIX to mainframe typically ran under virtual machine hypervisor ... since the effort to add 370 mainframe EREP support to unix was several times larger than simply porting UNIX to the mainframe (running in virtual machine hypervisor, UNIX could take advantage of EREP provided by the hypervisor). http://www.garlic.com/~lynn/2007m.html#69 Operating systems are old and busted in the payment gateway scenario ... we defined a matrix of about 40 failure scenarios and 5-6 states that might happen involving the webserver, the internet, and/or the payment gateway ... and had to show for every possible case, the situation could be automatically recovered from and/or failing component identified and diagnosed with a few minutes. some of this was philosophical. the basic internet payment process takes the messages defined for (circuit-based) operation between point-of-sale terminal and payment infrastructure. These messages defined for circuit-based operation were then just retargted to a internet, packet-based environment. Now, there are some number of implicit operational consideratiions that are part of a circuit-based infrastructure that are lost in migrating to packet-based operation. So some part of what we had to do was basically compensating processes to make up the difference between circuit-based operation and packet-based operation ... including the writing of a problem diagnosing manual. In the telco, circuit-based world, a call is made to the telco provider and all sort of magic automatically happens ... especially when there is a service-level agreement in place (something that has been slow coming to the internet world ... and still won't really address full end-to-end operation ... especially crossing several different service providers). by comparison, in that time-frame there was a situation ... where a (telco) central exchange mangled some 1-800 point-of-sale terminal calls for a period of 18 minutes ... which was treated as an enormously severe problem at the highest executive levels. another related scenario ... were various things ... in addition to use of PREPARE comand, automated operator (enabled with AUTOLOG command), and automatic reboot/restart .... enabling "lights out", unattended operation for off-shift timesharing use ... recent post that also touched on this subject: http://www.garlic.com/~lynn/2007m.html#68 Operating systems are old and busted other posts about operating online, commercial timesharing service http://www.garlic.com/~lynn/submain.html#timeshare i've since claimed that a lot of the operation of a lot of the large scale web-based services ... have a lot of the "human" free requirements that old-style mainframe operations had to evolve. This may be represented more of a philosophical challenge to many of the commingly used platforms for web services. A lot of these platforms evolved from an "interactive" environment ... where the operation of the machine was tied to interactions with some person. Many of the "batch" platforms evolved methodologies over periods of several decades ... assuming that the person responsible for the application wasn't present ... and therefor automated processes were needed for nearly all contingencies. In that sense, frequently the person responsible for a webserver operation may not be always available during periods that the webserver is operating. misc. past posts mentioning the 4-10 times rule-of-thumb: http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS) http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM http://www.garlic.com/~lynn/2003j.html#15 A Dark Day http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap ! http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto? http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions http://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications software definitions http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits http://www.garlic.com/~lynn/2006n.html#20 The System/360 Model 20 Wasn't As Bad As All That http://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now? http://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market(the sky is falling!!!the sky is falling!!) http://www.garlic.com/~lynn/2007h.html#78 John W. Backus, 82, Fortran developer, dies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Operating systems are old and busted Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 23 Jun 2007 18:49:43 -0600 another article on the same theme: Leopard and Vista: Last Gasp of the Big OS? http://news.yahoo.com/s/pcworld/133276 from above: Twenty years from now a new generation of computer users will look back on the operating systems of today with the same bemused smile we look back at the cars of the late 1950s and early 60s. They had huge fins, were the size of a small yacht and burned up just about as much gas. ... snip ... a few similar articles over the past yr: Windows Vista: The last Of Microsoft's Supersized Operating Systems? http://www.informationweek.com/blog/main/archives/2006/08/windows_vista_t.html Windows Vista the last of its kind http://www.techworld.com/news/index.cfm?NewsID=6718 Vista: The Last Microsoft Operating System that will Matter http://www.realtime-websecurity.com/articles_and_analysis/2007/01/vista_the_last_microsoft_opera.html Vista is the last of the dinosaurs http://www.theinquirer.net/default.aspx?article=36155 other recent posts in this thread: http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known To All http://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#68 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#69 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#73 Operating systems are old and busted
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 24 Jun 2007 12:06:47 -0600 timcaffrey@aol.com (Tim McCaffrey) writes: While I don't disagree about the Z-100 being a superior machine (still have one and parts for another). It wasn't introduced until March 1982, and it is very difficult to get one. I got my Z-100H in Dec. 83. the issue wasn't whether or not the Z-100 was a superior machine ... especially for consumer market place; the issue was where was critical market and what were customers basing their buying decision on. looking at purely (home) personal computing ... that would make Z-100 competing with trs-80 and commodore 64 ... which had the largest volumes in the (home) personal computing market. ... i.e. previous posts with reference to volumes by yr http://www.garlic.com/~lynn/2007m.html#63 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007n.html#0 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM big issue for ibm/pc was that its volumes selling into business market ... it wasn't heavily competing with volumes in the purely home personal computing market. the issue has been raised repeatedly that nobody got fired for buying IBM (in the business market). the other view point is that a lot of the people making buying decision (in the business market) wouldn't have technical expertise to make a distinction between two different "personal computers" ... aka at the time, the majority of the business people (making buying decision) wouldn't be able differentiate between the ibm/pc and say the Z-100 ... so buying decision is likely to be heavily influenced by lots of other factors; (business) brand recognition, whether they had seen sales pitch, etc (some of this is analogous to whether people buy brand names or generic in grocery stores), how exactly compatible they were (and any attempt to pitch significant differentiating features would, in turn undermine the compatibility theme). the clone business ... dating back to mainframe clone controllers in the 60s and mainframe clone processors in the 70s ... have tended to be based on being essentially identical and selling on price ... mostly able to get some small percentage of the market based purely on price. Big part of the issue in selling into the business market, was that there were only very small percentage of the decision makers that believe they had technical expertise that would enable them to make evaluation based on features. as a result, majority of clone marketing was based (effectively) on being identical and selling on price alone (with other differentiating features having little meaning to the majority of the buyers). So there might be some markets where differentiating features in something like Z-100 would have meaning to perspective buyers ... say putting them in competition with commodore 64 sales. In the (business) ibm mainframe terminal emulation market segment ... positioning would primarily be as a clone ... identical and selling purely on price (the brand name vis-a-vis generic scenario). Then a major issue is compatibility ... and thru the ages, some number of clones failed compatibility ... and was leveraged as marketing countermeasure against clone purchases. To get past the small percentage of early adopters ... specific clone vendors frequently had to somehow establish critical mass install base ... effectively brand name of their own (and as demonstration of true compatibility). This sort of market penetration scenario was seen in the mid-70s with clone (mainframe) processors ... and similar type progression could be seen in the mid-80s with clone personal computers. lots of pervious posts mentioning terminal emulation http://www.garlic.com/~lynn/subnetwork.html#emulation other posts in this specific thread: http://www.garlic.com/~lynn/2007m.html#42 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#44 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#45 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#48 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#50 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#57 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#72 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sun, 24 Jun 2007 13:58:29 -0600 timcaffrey@aol.com (Tim McCaffrey) writes: Lynn do you have any figures about how many PCs were sold into the corporate market vs. the home market in the first 18 months? (pre XT, in other words). I think most people don't appreciate how much leverage the corporate world has over the PC market. Which, of course, explains why certain things sucked on the PC for such a long time (graphics, sound, plug-n-play upgrades, etc), and other things were available very quickly (networking, printer sharing, hard disks, etc). re: http://www.garlic.com/~lynn/2007n.html#12 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM other than the overall numbers referenced in the previous posts: http://www.garlic.com/~lynn/2007m.html#63 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007n.html#0 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM I haven't yet found quotable numbers for break out of commercial vis-a-vis consumer. however, the previous references on overall market also do talk about the total number of different vendors in the (personal computing) market during the early 80s (couple hundred) ... and lots of confusion and compatibility issues ... especially with software/application life-cycle ... which was also somewhat the replay of driving factor behind 360 mainframes. however, his is somewhat different perspective on what it took to be a succesful clone in that time-frame: http://www.cwhonors.org/search/his_4a_detail.asp?id=3875 the above comments, from compaq perspective was that they got their foothold in the clone business by driving compatability search engine use uncovers a series of posts here which are extracts from articles in that time-frame including discussion of some of the market forces: http://www.amigau.com/68K/dg/dg.htm http://www.amigau.com/68K/dg/dg24.htm http://www.amigau.com/68K/dg/dg25.htm past post mentioning testimony in (mainframe) anti-trust litigation about industry awareness concerning market requirement for compatibility http://www.garlic.com/~lynn/2001j.html#33 Big black helicopters the above also makes reference to conversation with somebody that worked with TJW-jr, saying all the litigation took all the interest out of running the company since every (business) decision had to made from the standpoint of how might the gov. react. other past posts mentioning testimony in (mainframe) anti-trust litigation about industry awareness concerning market requirement for compatibility http://www.garlic.com/~lynn/94.html#44 bloat http://www.garlic.com/~lynn/96.html#20 1401 series emulation 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/2002d.html#26 looking for information on the IBM 7090 instruction set http://www.garlic.com/~lynn/2003o.html#43 Computer folklore - forecasting Sputnik's orbit with http://www.garlic.com/~lynn/2004d.html#22 System/360 40th Anniversary http://www.garlic.com/~lynn/2007e.html#18 Is computer history taught now? http://www.garlic.com/~lynn/2007f.html#77 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007m.html#34 IBM 8000 ???
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What if there were two Internets? Newsgroups: soc.history.what-if,alt.history.what-if,alt.folklore.computers,alt.fan.cecil-adams Date: Sun, 24 Jun 2007 17:30:17 -0600 Greg Goss <gossg@gossg.org> writes: *High Speed - terminology changes over the years That blindingly fast connection was 0.0096 megabit. re: http://www.garlic.com/~lynn/2007m.html#71 What if there were two Internets? http://www.garlic.com/~lynn/2007n.html#7 What if there were two Internets? misc past posts with references to mid-80s "high-speed" ... during period we were doing some stuff somewhat related to nsfnet http://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT) http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink) http://www.garlic.com/~lynn/2003m.html#59 SR 15,15 http://www.garlic.com/~lynn/2004g.html#12 network history http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP http://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits http://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design http://www.garlic.com/~lynn/2005u.html#57 IPCS Standard Print Service http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication http://www.garlic.com/~lynn/2006l.html#4 Google Architecture http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders? http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What if phone company had developed Internet? Newsgroups: soc.history.what-if,alt.history.what-if,alt.fan.cecil-adams Date: Sun, 24 Jun 2007 20:22:03 -0600 mailbox writes: Restating my earlier query and adjusting the newsgoups line so as not to get sidetracked on the technical aspects: What if the phone company had developed the Internet? What would we be paying for access? Would e-mail be metered? Would there be spam? Would there be Google?..etc. the folklore is that the national PTTs were substantially behind OSI ISO/ITU-T standards ... basically very traditional copper link/circuit oriented. http://www.itu.int/net/home/index.aspx http://en.wikipedia.org/wiki/ITU-T at various points there were even national edicts that internetworking would be eliminated and replaced it with OSI. also take a look at ISDN, X.25, VAN (value added networks), EDI, X.400, X.500, etc standards. Various VAN/EDI offerings, in fact, offerred metered email. However, most all of this were targeted at commercial entities (in part because the pricing structure) and saw little or no use in consumer market segment. internetworking has nearly supplanted nearly all of the (commerical) VANs that had grown up in the 70s & 80s. In that sense ... they DID develop their own online offerings ... which eventually gave way to the internet ... i.e. it wasn't "IF" ... they DID ... but of course, they weren't going to look like THE INTERNET. In that sense the telco "developed" internets lost out to THE INTERNET. While ISO wasn't limited to PTTs, one major differentiation between IETF (and the internetworking standards) and ISO ... was that IETF requires demonstration of multiple interoperable implementations as standard progression ... while ISO can pass a standard w/o ever demonstrating that it was practical and/or even possible. some past posts mentioning some of the issues/activities going on around OSI and ISO http://www.garlic.com/~lynn/subnetwork.html#xtphsp Even after (NSFNET backbone) broke out into commercial with CIX, peering-aggreements, etc ... various telcos continued to be involved in various parts of internetworking activity. we had been called in to consult with a small client/server startup that wanted to do payments on their server ... and they had this technology called SSL (the result is frequently now referred to as electronic commerce). Part of the effort was something called a payment gateway ... misc. past posts referencing payment gateway http://www.garlic.com/~lynn/subnetwork.html#gateway they had this project called a "commerce server" ... which happened to be run by two people we had worked with in previous life ... a couple refs http://www.garlic.com/~lynn/95.html#13 http://www.garlic.com/~lynn/96.html#15 the implementation started off being a "mall" paradigm ... designed to be hosted by service provider ... with merchants "leasing" space/services in the "mall". there were lots of effort equated various implementation pieces with the physical mall paradirm. there is some possibility that this whole initial effort was underwritten by one of the telcos. this fairly quickly gave way to another implementation where each merchant could field their own electronic commerce webesrver. part of the issue is the mall construct fundamentally provides a physical/time solution for customers (large number of merchants in a physical compact space, simplifying access for customers). one of the attributes frequently ascribed to the internet is that it eliminates physical distances (all by itself) ... aka customers can visit a large number of different merchants at distinct different webservers. the online mall possibly would have greater appeal if customers actually had to make unique circuit connections (different phone calls) to specific sites (i.e. vestiges of circuit-based orientation in contrast to packet oriented internetworking). with world-wide internetworking "anarchy" ... there is no service provider that is responsible for establishing directory for everything available online. this free-for-all anarchy eventually allowed huge explosion in online content (which would have been extremely difficult in a more structured PTT environment) ... and gave rise to the requirements for "search engines" ... aka "what is there" and "where can it be found".
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What if phone company had developed Internet? Newsgroups: soc.history.what-if,alt.history.what-if,alt.fan.cecil-adams Date: Sun, 24 Jun 2007 20:43:00 -0600 "William Black" <william.black@hotmail.co.uk> writes: The Internet started as a means of passing military communications. The message was there before the medium re: http://www.garlic.com/~lynn/2007n.html#15 What if phone company had developed Internet? the arpanet started as packet-switched network that could possibly be routed via a number of different paths. however, the implementation was still a single network with homogeneous interface provided by IMPs. it didn't support internetworking. somewhere along the way ... there was the realization that large complex environments were going to require "internetworking" ... implicit assumption was to provide internetworking between multiple, independent networks. i've frequently claimed that the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet was larger than the arpanet/internet (from just about the beginning until sometime mid-85) because it early on provided for a layered, gateway kind of function (which the internet finally got in the switchover from arpanet to internetworking). the great switchover from arpanet to internetworking occured on 1jan83 ... eliminating many of the growth inhibitors that were present in the homogeneous arpanet/imp paradigm ... contributing to it be able to exceed the internal network in size. the relative interconnect anarchy provided by the internetworking functionality was something alien to telco/PTT way of doing business ... since they had been used to directly providing all communication capability (explicit point-to-point operation for every communication). posts in the previous thread: http://www.garlic.com/~lynn/2007m.html#71 What if there were two Internets? http://www.garlic.com/~lynn/2007n.html#7 What if there were two Internets? http://www.garlic.com/~lynn/2007n.html#14 What if there were two Internets?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What if phone company had developed Internet? Newsgroups: soc.history.what-if,alt.history.what-if,alt.fan.cecil-adams Date: Mon, 25 Jun 2007 08:58:13 -0600 BernardZ <bernardZ@BluesystemNospam.com> writes: Actually phones using bulletin boards were popular with computer nerds in the early 1990s. a large part of csnet in the late 70s/early 80s used "phonenet" ... reference to "phonenet" connection ... old email describing csnet connection options (including "phonenet" http://www.garlic.com/~lynn/internet.htm#email821022 in this post http://www.garlic.com/~lynn/internet.htm#0 this was even before arpanet moved off their IMP implementation and supported internetworking. usenet in the late 70s started with "phonenet" store&forward. some number of the bulletin boards in the early 90s were also usenet servers (using phone calls). In the early 90s, I had a ms/dos platfrom running waffle ... but I had also done a satellite modem driver for company offering usenet feed via satellite (so they provided me with free dish and modem). dish was slightly larger than the current generation of satellite TV dishes. I also co-authored article on the driver and service for boardwatch magazine (included picture of me standing next to the dish in backyard). should make some distinction between using phone calls for computer networking ... and using phone calls for terminal dial-in to computer (whether originating real terminal or a PC emulated terminal with something like kermit). terminal dial-in operation to computer has been around since at least 50s&60s (teletype terminals with 110 baud modems). i had gotten a home terminal with dial-in access in march of 1970 ... and had it until upgrading to PC ... with terminal emulation dialin. some number of commercial timesharing services started cropping up in the 60s ... offering terminal dialin ... lots of collected past posts about some of the commercial timesharing services http://www.garlic.com/~lynn/submain.html#timeshare an example would be vm370-based TYMSHARE ... started in the early 70s. They also developed their own private operated value-added-network that they called TYMNET. The installed POPs (point-of-presence) phone numbers in large number of cities for terminal dial-up access ... and used TYMNET to communicate between the POPs and their TYMSHARE service. They also started offering TYMNET to corporations that were looking providing remote terminal access to in-house corporate computer service. When M/D bought up TYMSHARE in the 80s, TYMNET was spun off to british telecom (moving into the states). Something similar was emulated yrs later ... with service providers offering dial-up access into online and/or internet access (some number of service providers actually subcontract "local" modem dial-up POPs to other operations). One of the early hardware vendors into this market was Livingston which had a combo "terminal" concentrator ... that evolved from terminal (or terminal emulation) into acomputer service, then SLIP support and then finally PPP ... with internet routing out the back-end (I had done some work helping configure Livingston boxes in the early/mid 90s). Part of what Livingston developed was an authentication protocol called RADIUS. Livingston was eventually bought up and went thru a number of transition that unlikely any vestiges survive. However RADIUS was "donated" to the IETF for internet standard and continues to survive today as the dominate form of authentication used to connect into ISP (even when it doesn't actual involve a dial-in connection). from my internet standards index: http://www.garlic.com/~lynn/rfcietff.htm click on Term (term->RFC#) (in RFCs listed by section), then click on "RADIUS" in the Acronym fastpath: remote authentication dial in user service (RADIUS ) see also authentication , network access server , network services 4849 4818 4679 4675 4673 4672 4671 4670 4669 4668 4590 4372 4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058 clicking on any RFC number brings up the RFC summary in the lower frame, clicking on the ".txt=nnn" field in a summary, retrieves the actual RFC. other collected posts mentioning RADIUS http://www.garlic.com/~lynn/subpubkey.html#radius for other topic drift, past posts mentioning boardwatch http://www.garlic.com/~lynn/2000.html#38 Vanishing Posts... http://www.garlic.com/~lynn/2000e.html#39 I'll Be! Al Gore DID Invent the Internet After All ! NOT http://www.garlic.com/~lynn/2001h.html#66 UUCP email http://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration http://www.garlic.com/~lynn/2006m.html#11 An Out-of-the-Main Activity
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 25 Jun 2007 09:22:24 -0600 lists@ibm-main.lst (Phil Smith III) writes: Re VAX vs. IBM: I was a central, low level member of the 4300 series. I also led the engineering side of the fight against the VAX. We never approached the installed base of the VAX machines. Never. approach the size of the install base in number of customers or number of machines or competitive marketing approaching the customers that bought vaxes? past post giving decade of vax install numbers sliced and diced by model, yr, domestic, non-domestic, etc: http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction both 43xx and vaxes saw huge uptake in the early 80s with the growth of the department market ... which was starting to move into workstations and PCs by the mid-80s. as above, the big volumes for VAXes in the mid-80s were from micro-vax ... not traditional 780 machines. lots of vaxes were customer orders for one or a very few. vaxes had an advantage here since their installation and support required a lot less effort (something that 43xx was constantly fighting ... there were even some SHARE reports highlighting the resource requirement differences in competitive environment). however, there were some number of large customers that ordered 43xx boxes in large lots (sometimes hundreds, even large hundreds). the resource support requirement competitive advantage (in small shops) was mitigated when amortized across a large number of boxes. old email about specific customer ordering in hundreds (customer initially thot 20, but order was finally for 210): http://www.garlic.com/~lynn/2001m.html#email790404 in this post also discussing other "departmental computing" issues from the period http://www.garlic.com/~lynn/2001m.html#15 departmental server lots of old email discussing various aspects of 43xx ... use for clustering and/or distributed, departmental computing http://www.garlic.com/~lynn/lhwemail.html#43xx
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 25 Jun 2007 09:42:32 -0600 lists@ibm-main.lst (Phil Smith III) writes: Re RISC vs. 68K: Anyone who thinks the RISC chips killed the 68K is off base. They just need to check the dates. Intel killed the 68K. Motorola allied with IBM on RISC only after Intel had destroyed Motorola's market for the 68K. 801 was originally targeted (very) low-end ... ROMP chip was targeted to be used in a displaywriter follow-in ... when that project was killed, the group looked around for something to save the effort ... and hit on the unix workstation market (with the displaywriter follow-on morphing into unix workstation). lots of unix workstation market place is very numerical and power hungry ... somewhat as a result ... the followon to ROMP for that market was large, power-hungry RIOS chipset (i.e. POWER, announced in RS/6000). Paperweight on my desk (from original) has six chips, and says 150 million OPS, 60 million FLOPS, and 7 million transistors. somerset was combined ibm, motorola, apple project to do a single chip, 801 PC-level implementation ... the executive we reported to when we were doing ha/cmp http://www.garlic.com/~lynn/subtopic.html#hacmp went over to head up somerset. part of somerset including infusing power/pc with some of motorola's 88k (risc) technology. ROMP and RIOS were single processer implementations with no provision for multi-processor cache consistency. power/pc was going to be able to support cache consistency and multiprocessor operation. lots of past 801 posts http://www.garlic.com/~lynn/subtopic.html#801 68k was still hanging in there in 89/90 time-frame ... a couple posts with some old references from the period (raw chip volumes, business analysis, etc) http://www.garlic.com/~lynn/2005q.html#35 Intel strickes back with a parallel x86 design http://www.garlic.com/~lynn/2005q.html#44 Intel strickes back with a parallel x86 design
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 25 Jun 2007 11:42:00 -0600 re: http://www.garlic.com/~lynn/2007n.html#18 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM the place that 43xx had the most difficult competition against vax/vms was in the single (at a time) departmental servers (as some of the SHARE studies highlighted). cost of mid-range computers had dropped below a threshold that made them very cost-effective in departmental settings ... however scarce people skills and costs then started to dominate as market inhibitor. 43xx did do very well in large number of departmental server orders (especially with distributed, networked operation) ... where people support skill/costs could be amortized across large number of machines. clusters of 43xx also started to impact 3033. at one point (traditional internal politics), the head of pok, manipulated east fishkill to cut the allocation in half of a critical component needed for 43xx manufacturing. later the same person gave a talk to a large public audience and made some statement that something like 11,000 vax/vms orders should have been 43xx ... also referenced in this old post http://www.garlic.com/~lynn/2001m.html#15 departmental servers and old email mentioning various 43xx issues ... including moving workload off 3033 boxes onto 4341 clusters ... and large distributed departmental server operations. http://www.garlic.com/~lynn/lhwemail.html#43xx
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 25 Jun 2007 12:27:44 -0600 eugene@cse.ucsc.edu (Eugene Miya) writes: No, the most difficult competition was and is against the IBM PC. If it did so well, we'd see more evidence of it being around. They are not even museum pieces. re: http://www.garlic.com/~lynn/2007n.html#20 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM you didn't read the zillion previous posts mentioning that mid-range market for both vax/vms and 43xx volumes in departmental server market started to move to workstations and larger PCs in the mid-80s. above reference post ... mentions the previous post in the thread ... which made the same point one more time (and then later the workstations started to also loose out to PCs). http://www.garlic.com/~lynn/2007n.html#18 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM for instance, the 4361/4381 which were expecting similar large volume sales as seen for 4331/4341 ... never happened. similar numbers can be seen for vax/vms numbers ... where vax did do some volumes in the mid-80s with micro-vax ... also readily seen in the repeated references to decade of vax/vms numbers, sliced & diced by model, yr, domestic, world-wide, etc http://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction ... the 4331s/4341s and other mid-market players in the departmental servers had very little PCs to compete with (late 70s and early 80s) ... it wasn't until you get to the followon machines; 4361s/4381s (and later vax) that you start to see the workstation/PC effect in the departmental server market. one of the contributions to the PCs in the departmental server market was a project called DataHub which was being done by the san jose disk division. Part of the software implementation was being done under work-for-hire subcontract by a group in Provo (one of the people from San Jose commuted to Provo nearly every week). At some point, the company decided to kill the DataHub project and allowed the Provo group to retain rights to everything that they had done under the work-for-hire contract. Not too long later, there was a company out of Provo with a PC server offering. misc. past posts mentioning DataHub project: 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 ? http://www.garlic.com/~lynn/2005q.html#36 Intel strikes back with a parallel x86 design http://www.garlic.com/~lynn/2006l.html#39 Token-ring vs Ethernet - 10 years later http://www.garlic.com/~lynn/2006y.html#31 "The Elements of Programming Style" http://www.garlic.com/~lynn/2007f.html#17 Is computer history taught now? http://www.garlic.com/~lynn/2007j.html#49 How difficult would it be for a SYSPROG ? in the mean time, the communication division had seen a huge install base of communication controllers grow based on terminal emulation http://www.garlic.com/~lynn/subnetwork.html#emulation which was started to break away into various kinds of client/server ... they came up with SAA ... somewhat positioned at helping preserve their communication controller market (and countermeasure to client/server). A problem we had in this period was that we were making some number of customer executive presentations on 3-tier (network) architecture ... and taking flames & barbs from the SAA factions http://www.garlic.com/~lynn/subnetwork.html#3tier other recent posts in this same thread: http://www.garlic.com/~lynn/2007m.html#42 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#44 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#45 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#48 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#50 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#57 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#63 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007m.html#72 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007n.html#0 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007n.html#12 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007n.html#13 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM http://www.garlic.com/~lynn/2007n.html#19 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What if phone company had developed Internet? Newsgroups: soc.history.what-if,alt.history.what-if,alt.fan.cecil-adams Date: Mon, 25 Jun 2007 13:27:10 -0600 Bob Ward <bobward@email.com> writes: You missed out on the first ten years of BBS's? I was running the ASCII Attic in San Bernardino, CA in the early 80's... re: http://www.garlic.com/~lynn/2007n.html#15 What if phone company had developed Internet? using csnet http://www.garlic.com/~lynn/internet.htm#0 doing high-speed backbone http://www.garlic.com/~lynn/subnetwork.html#hsdt on the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet internal network announcement of 1000th node ... not too long after the great arpanet-to-internet conversion (which was somewhere between 100 nodes and 255 nodes ... depending on how you count) http://www.garlic.com/~lynn/internet.htm#22 other references to locations that added one or more internal network nodes during 1983 (over 100 different locations, including most major cities around the world) http://www.garlic.com/~lynn/2006k.html#8 Arpa address also working with the people trying to put in place nsfnet backbone .... various old email references http://www.garlic.com/~lynn/lhwemail.html#nsfnet and posts http://www.garlic.com/~lynn/subnetwork.html#nsfnet at one point, the internal high-speed backbone ... providing austin access to LSM (high-speed vlsi chip logic simulator) in los gatos was credited with helping bring in the RIOS chipset (aka power, rs/6000) a year early. ... recent post/ref http://www.garlic.com/~lynn/2007m.html#61 Is Parallel Programming Just Too Hard? one of the issues with internal network links were that everything leaving a corporate facility had to be encrypted. this wasn't too bad for slower-speed links ... but got a lot harder for some of our higher-speed stuff and also for links that cross national boundaries (even if it was between sites for the same corporation). comment in the mid-80s that the internal network had over half of all the link encryptors in the world. misc. old email mentioning different kinds of crypto http://www.garlic.com/~lynn/lhwemail.html#crypto other posts in these threads: http://www.garlic.com/~lynn/2007m.html#71 What if there were two Internets? http://www.garlic.com/~lynn/2007n.html#7 What if there were two Internets? http://www.garlic.com/~lynn/2007n.html#14 What if there were two Internets? http://www.garlic.com/~lynn/2007n.html#16 What if phone company had developed Internet? http://www.garlic.com/~lynn/2007n.html#17 What if phone company had developed Internet?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What if phone company had developed Internet?
Newsgroups: soc.history.what-if,alt.history.what-if,alt.fan.cecil-adams
Date: Mon, 25 Jun 2007 14:38:13 -0600
Bob Ward <bobward@email.com> writes:
You missed out on the first ten years of BBS's? I was running the
ASCII Attic in San Bernardino, CA in the early 80's...
re:
http://www.garlic.com/~lynn/2007n.html#15 What if phone company had developed Internet?
http://www.garlic.com/~lynn/2007n.html#22 What if phone company had developed Internet?
oh ... and i got to do a lot of the stuff for online machine at the
science center ... write a lot of the kernel software, do a lot of the
production operational support ... when I got my home terminal in mar
1970 ... it was where I would dial-in to to get online access.
the science center, 4th flr, 545 tech sq was also where virtual machines
originated (with cp40 in the mid-60s),
http://www.garlic.com/~lynn/subtopic.html#545tech
the internal network started
http://www.garlic.com/~lynn/subnetwork.html#internalnet
GML was invented ... precusor to SGML, HTML, XML, etc
http://www.garlic.com/~lynn/submain.html#sgml
a recent post tracing some of the evoluation ... with a little
RDBMS archeology also thrown in
http://www.garlic.com/~lynn/2007j.html#24 Newbie question on table design
Both CERN and SLAC ("sister" high energy physic installations) were large
vm370/cms shops (virtual machine cp67 system which morphed into virtual
machine vm370 system in the 70s); reference to to CERN HTML evolving out
of CMS/GML
http://infomesh.net/html/history/early/
and first webserver outside europe was on slac's vm370 system
http://www.slac.stanford.edu/history/earlyweb/history.shtml
some amount of online, commercial timesharing in the late 60s and 70s
was based on the virtual machine technology (cp67 and later vm370) from
the science center
http://www.garlic.com/~lynn/submain.html#timeshare
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What if phone company had developed Internet?
Newsgroups: soc.history.what-if,alt.history.what-if,alt.fan.cecil-adams
Date: Tue, 26 Jun 2007 04:57:53 -0600
Bob Ward <bobward@email.com> writes:
As I said, all this claimed experience, but no knowledge of the BBS
world before the early 1990's?
re:
http://www.garlic.com/~lynn/2007n.html#22 What if phone company had developed Internet
my earlier reference was operating my own bbs platform on ms/dos
platfrom using waffle and supporting satellite usenet feed (in the
early 90s)
http://www.garlic.com/~lynn/2007n.html#17 What if phone company had developed Internet
i thot your previous comment appeared to imply what i supported/used
in the 70s & 80s ... as opposed knowledge of.
however, from long ago and far away ... old usenet reference from
early 80s:
To: wheeler
Date: 10/27/83 17:10:13
The following comes to me from a non-IBM friend, who found it on the
Usenet (Unix Network) Bulletin Board System...
"There are a few chip designers and sellers at Intel (the rumor goes)
who would like to shoot Bill Gates right now. It seems the Microsoft
folks can't read, and as a result Intel has a large pile of 80188s it
can't ship. And Intel is redesigning the 80188 chip. Again."
"It's like this: the 8088 spec sheet reserves two of the 256 jump
vector addresses for future Intel use. Microsoft went ahead anyway
and used them in the MS-DOS operating system anyway. The large pile
of 80188s that Intel can't ship use those two reserved vectors for a
hardware purpose... Unfortunately, there are about 12,000 application
programs sitting on computer retailer's shelves all over the country
which call those vectors... Since Intel's documentation scrupulously
documented that those two vectors are reserved, they are (the rumor
goes) refusing to take back the 80188s (already) sold, unless (the
rumor continues) the customer uses a blue logo with three alphabetic
characters."
And now you know why Peanut hasn't been shipped yet, and what CPU
Peanut uses. We wonder how long it will take Intel to change the mask
-- again -- and get the chip back into production -- again?
... snip ... top of post, old email index
lots of csnet used phonenet ... and gatewayed "bang" addresses that
would propagate thru the csnet interface ... i.e.
http://www.garlic.com/~lynn/internet.htm#0
other, not necessarily related old email back to early 70s
http://www.garlic.com/~lynn/lhwemail.html
test email thru the csnet gateway:
Date: 13 Jan 1983 16:42:28PST
From: xxxx@xxxxx.UUCP at UDel-Relay
Return-Path: <xxxx@xxxxx.UUCP>
Date: 12-Jan-83 03:57:58-PST (Wed)
From: xxxx@xxxx.UUCP.Berkeley.ARPA
Subject: hi there
Received: by UCBVAX.BERKELEY.ARPA (3.293 [1/9/83])
id AA10567; 12-Jan-83 03:57:58-PST (Wed)
Received: from UCBVAX.BERKELEY.ARPA by udel-relay.ARPA (3.284 [1/5/83])
id AA07867; 13-Jan-83 16:42:08-EST (Thu)
Message-Id: <8300121157.10567@UCBVAX.BERKELEY.ARPA>
To: ucbvax!decvax!harpo!seismo!hao!hplabs!sri-unix!wheeler.IBM-SJ@Udel-Relay.ARP
does this work?
... snip ... top of post, old email index
same person shortly later forwarded:
From ucsfcgl!ucbvax!mhtsa!ihnss!harpo!npois!jak Fri May 21 13:55:19 1982
Subject: all 7 old decwars articles
Newsgroups: net.sources
Subject: DEC WARS
Have you ever wondered what happened to all those characters eaten by
arpavax? Well, we found most of them loitering around on our system,
taking up disk space. So we're putting them back out on the net where
they belong. Any resemblence to events real or imagined is purely
intentional.
A long time ago, on a node far, far away (from ucbvax).....
XXXXX XXXXXX XXXX * X X XX XXXXX XXXX X
X X X X X X X X X X X X X
X X XXXXX X X X X X X X XXXX X
X X X X X XX X XXXXXX XXXXX X X
X X X X X XX XX X X X X X X
XXXXX XXXXXX XXXX X X X X X X XXXX X
... snip ...
the actual file is much longer
however, quick check with search engine and slightly later version can
be found here:
http://www.skepticfiles.org/cowtext/100/dec~1war.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 26 Jun 2007 08:26:07 -0600 Anne & Lynn Wheeler <lynn@garlic.com> writes: a couple recent items: re: http://www.garlic.com/~lynn/2007l.html#60 Is Parallel Programming Just Too Hard? another: Maryland Professor Creates Desktop Supercomputer Prototype http://www.newswise.com/articles/view/531072/?sc=rsbn from above: But no advancements in clock speed have been achieved since 2004. From an early stage, Vishkin foresaw that Moore's Law would ultimately fail to help improve clock speed due to physical limitations. This has guided his perseverance over his professional career in seeking to improve computer productivity by distributing the load among multiple processors, accomplishing computer tasks in parallel. ... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: VM system kept NYSE running Newsgroups: alt.folklore.computers Date: Tue, 26 Jun 2007 16:08:13 -0600 here is reference to some mainframe history including NYSE MDS-II, originally on a pair of specially duplexed 360/50s, which was upgraded to run in vm/4341 virtual machine lifetime) http://www.raylsaunders.com/asmwork.html or wayback machine http://web.archive.org/web/20060220161415/http://raylsaunders.com/asmwork.html Minor typo in the above ... mentions MVS-Release 11 ... but obviously should be MFT-Release 11 (MVT came with Release 12 or 13). One of the description is about author processing information from other users ... using a process that originated in the 60s on cp67 and remained relatively unchanged through the addition of networking and whether it involved exchange between two users on the same machine or different machines. old post with copy of one of my versions that provided similar functionality to the what was mentioned in the above: http://www.garlic.com/~lynn/2004b.html#56 Oldest running code the example exec takes advantage of the fact that in CMS, (initially) all kernel system APIs, command line input, and exec (command script) processing are done by a common routine. With minimal hack it is possible to take something that is an assembler program kernel API and use it directly in in an exec (command script). My exec (included in the referenced post) includes what is nominal an assembler kernel API call to WAIT on (ready) interrupt from reader (indicating new arrival). The trailing garbage characters on the "WAIT RDR1RDR1" line are supposed to be 8 bytes of binary zeros, which is a standard way to terminate CMS kernel API parameter list.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What if phone company had developed Internet? Newsgroups: soc.history.what-if,alt.history.what-if,alt.fan.cecil-adams Date: Wed, 27 Jun 2007 11:59:22 -0600 ncwaite writes: Phone companies used to supply some content. The Speaking Clock is probably the best example, but in the old days of the British GPO, you had Directory Enquiries, Weather Reports and even the Recipe of the Day. I read once that in the very early days of the telephone (before regular radio broadcasts started), it was proposed that people could listen in to concerts via the telephone. You could describe this as a Victorian version of media streaming. re: http://www.garlic.com/~lynn/2007n.html#15 What if phone company had developed Internet? one of the telcos that provided a lot of the services for NSFNET backbone, misc. old email http://www.garlic.com/~lynn/lhwemail.html#nsfnet (aka tcp/ip is technology basis for modern internetworking, nsfnet backbone was the operational basis for modern internetworking, and cix & peering aggreements was the business/commercial basis for modern internetworking) .... appeared to also underwrite the cost of developing the electronic commerce "mall metaphor" webserver (anticipating that they would be the major service provider for that capability). this didn't appear to really take off ... and then a "stripped" down electronic commerce webserver version was then done for individual merchants ... we had been called in to consult with this small client/server startup that wanted to do payment transactions on this thing that they were calling commerce server (and had this new technology they were calling SSL). http://www.garlic.com/~lynn/subnetwork.html#gateway businesses that now do (individual) webhosting have since come into play ... but these tend to be individual web servers (as opposed to the mall metaphor webserver). for other drift, one of the new buzzwords is "server consolidation" ... i.e. frequently involving combinations of (floor/space saving) "blades" and "virtualization" (leveraging virtualization to compensate for most webservers tending to have very low, sporadic and/or bursty utilization patterns). and of course, virtual machines are the 40yr old, new thing ... courtesy of the science center, 4th flr, 545 tech. sq http://www.garlic.com/~lynn/subtopic.html#545tech where gml was also invented ... precursor to sgml, html, xml, etc http://www.garlic.com/~lynn/submain.html#sgml as well as the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet aka, previous post http://www.garlic.com/~lynn/2007n.html#23 What if phone company had developed Internet?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Wed, 27 Jun 2007 19:37:47 -0600 HP fires up Multi-Core Aid effort http://www.theregister.com/2007/06/27/hp_multicore_mop/ from above ... HP has located a few friends, including Intel and AMD, to help it deal with the multi-core processor morass. The hardware vendor has invited chums to join its new Multi-Core Optimization Program (MOP), which will support work that makes software run better across chips with numerous processor cores. ... snip ...
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Programmable TLB management? Newsgroups: comp.arch Date: Thu, 28 Jun 2007 05:26:44 -0600 John Mashey <old_systems_guy@yahoo.com> writes: This bug, of course, confirmed the argument of the OS people who'd fought with bugs for years in complex hardware MMUs, and had bigged the chip designers for the most minimalist MMU we could get ... and even that had a bug. It was unsurprising that early 1980s micros often had MMU bugs, and OS programmers hated them. 360/67 had a bug in the associative array (i.e. used by 360/67 for TLB) that charlie (aka compare&swap, CAS, charlie) found circa 1970 (nearly 40yrs ago). on page fault interrupt, the 360/67 cleared all the associative array entries to zeros w/o setting the invalid bits (bug). this hadn't been uncovered since the kernel would eventually do LCTL of CR0 (the segment table pointer) which would reset the associative array, and all entries would have invalid flag turned on (i.e. associative array only handled single address space, and any reload of the virtual address space table pointer would reset all the entries, even if it was for the same virtual address). so charlie was attempting to eek a couple extra cycles (in kernel interrupt handling) by eliminating unnecessary LCTLs, resetting the associative array. The hardware bug was that now all entries in the associative array were set to map virtual page zero to real page zero ... and if the page fault handling could be done w/o switching to different address space (like if the page invalid bit was on, but virtual page still in real storage and could be "reclaimed"), then there was some chance the virtual address space execution and/or the system might have some explained anomolous behavior. Kernel software work around was to make sure that LCTL was always done.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How would a relational operating system look like? Newsgroups: comp.databases.theory Date: Thu, 28 Jun 2007 14:13:32 -0600 Cimode <cimode@hotmail.com> writes: Hi, Lately, I came to put a version of Microsoft Vista on my desktop. As I am accustomed to with Microsoft OS's, I am bracing for the impact of how much extra RAM will be consumed when adopting a new generation of OS to make it function prperly. For Vista, I found out it is a nightmare! To make the usual applications I use (mainly administration tools), no less than 4Gb of RAM are required to avoid the screen *hanging on*/reeze effect one gets when openning several applications simultaneously. As a result I went back to XP Pro more and more despaired by the utter unefficiency of current OS and Environments. Convinced that a perfect OS is nothing else than a relational OS, I kept dreaming about building one someday. do a little cleaning of boxes in the basement, found Notes On Data Base Operating Systems, RJ1288, 2/23/78, 111pgs, James Gray. ABSTRACT: This paper is a compendium of data base management operating systems folklore. It is an early paper and is still in draft form. It is intended as a set of course notes for a class on data base operating systems. After a brief overview of what a data management system is, it focuses on particular issues unique to the transaction management component especially locking and recovery. misc. other posts mentioning system/r http://www.garlic.com/~lynn/submain.html#systemr the bibliography from a System R web site: http://www.mcjones.org/System_R/bib.html also mentions that the above paper appeared in "Operating Systems: An Advanced Course", Springer-Verlag, 1978, p. 393. The document is standard CMS script (gml) document format (reproduced from copy printed on 1403/3211 with TN chain). Virtualized CMS was standard internal personal computing environment ... first with cp67 which later morphed into vm370. The system/r implementation was done as virtualized operation under vm370. This is 40yr old new thing, now starting to take on renewed life. For a little topic drift in this thread: http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#65 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#67 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#68 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#69 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#73 Operating systems are old and busted http://www.garlic.com/~lynn/2007n.html#11 Operating systems are old and busted with some references: Operating systems are old and busted http://www.theregister.com/2007/06/20/usenix_07_opening_keynote/ Operating systems are old and busted http://www.channelregister.co.uk/2007/06/20/usenix_07_opening_keynote/ Leopard and Vista: Last Gasp of the Big OS? http://news.yahoo.com/s/pcworld/133276 Leopard and Vista: Last Gasp of the Big OS? http://www.pcworld.ca/news/column/63b28a3a0a01040801e9093a3cb7de53/pg0.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM obsoleting mainframe hardware Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Fri, 29 Jun 2007 12:13:05 -0600 rfochtman@ibm-main.lst (Rick Fochtman) writes: If the business needs are being satisfied, with reasonable economy, who cares whether the box is "the lastest and greatest"? Future business needs may or may not dictate upgrades. YMMV a little search engine mainframe surfing for vm/4341 turned up this story about a vm/4341 keeping the nyse running well thru the 80s ... apparently with an old mvt system that had been moved from 360/50s http://www.raylsaunders.com/asmwork.html that i mentioned in this recent post: http://www.garlic.com/~lynn/2007n.html#26 VM system kept NYSE running a quick check just this moment, turns up some problem with the URL ... but (as always) the wayback machine knows http://web.archive.org/web/20060220161415/http://raylsaunders.com/asmwork.html for other topic drift ... we spent some amount of time in the early 90s talking to SIAC about using ha/cmp for much of the work that the tandems were doing (see mainframe MDS-II being replaced with tandem MDS-IIIs in the above reference) ... lots of ha/cmp references: http://www.garlic.com/~lynn/subtopic.html#hacmp this was in the period that we were also working on ha/cmp scaleup and trying to cram as much computing into dense footprint, old email references: http://www.garlic.com/~lynn/lhwemail.html#medusa I had actually attempted to do something similar nearly a decade earlier with trying to cram as many 370 chipsets (each had about 168-3 thruput) as possible into racks. the old 8-10 yr cycle for mainframe generations (and obsolescence) really showed up when the early 70s FS project was killed http://www.garlic.com/~lynn/submain.html#futuresys since FS was going to be something completely different, much of the work on 370 related stuff pretty much went away. after FS was killed, there was a scramble to get stuff back into the 370 product pipeline. 370-xa/3081 was going to take eight yrs (early 80s) ... so they had to find something else that could be done in possibly half that time. the resulting 303x was quite a bit of warmed over 370. they took the intergrated channel microcode from 158 and made it stand-alone box called channel director. Then 158 paired with a channel director became 3031 (with integrated channel microcode running on different processor). 168 became 3032 repackaged to work with channel director. 3033 started out as 168 wiring diagram implemented with faster chip technology. straight-forward mapping would have just been 20percent faster than 168 ... other tweaks done during development got 3033 up to 1.5times 168. part of the issue was that up to the 80s, lots of technology was on 7-10yr cycle ... where in the 80s, the rate of change started to accelerate; for a time, leaving some mainframe technology in the dust. note that it wasn't just mainframes. circa 1990, the US automobile (C4) task force looked at being able to accelerate (cut in half) US automobile product cycle from 7-8yrs (in attempt to get on level playing field with some of the imports). it was interesting to watch what the mainframe people were saying in the meetings (since, at the time, they were effectively in the same boat). one of the things that the automobile industry had been doing would run parallel new product projects offset by four yrs (so it appeared that something new was coming out every four yrs). the analogy for mainframes ... was as soon as 3033 was out the door, they started on 3090 (overlap with 3081 with 4yr offset). in fairly stable industry this worked since consumer tastes weren't signicantly changing. However the 8yr lag could become significant if there was any significant change in what the market place was looking for (giving vendors that had much shorter product cycle a competitive edge). some recent references to C4 effort circa 1990 ... attempting to improve competitive footing vis-a-vis several imports: http://www.garlic.com/~lynn/2007f.html#50 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007g.html#29 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT Competitiveness http://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT Competitiveness http://www.garlic.com/~lynn/2007i.html#13 U.S. Cedes Top Spot in Global IT Competitiveness http://www.garlic.com/~lynn/2007j.html#33 IBM Unionization
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What I miss in my OS Newsgroups: alt.folklore.computers Date: Sat, 30 Jun 2007 16:54:20 -0600 Charlton Wilbur <cwilbur@chromatico.net> writes: Thus, if somehow I am transported back to BAH's circa-1980 workflow and a developer hands me a bunch of edits on paper, I can make each one and save the file, and get the benefits of BAH's no-backups approach. The existence of automatically saved backup files should be no hindrance to using a workflow that's been outdated for the past 20 years. cp67/cms supported a single "update" file to a particular source file ... and you had to "edit" the update file ... along with all the control stuff. very early 70s, this was augmented with an iterative process that would cycle thru a number of cascading "updates" (part of multi-level update project to support unanounced 370 architecture features under cp67). later in the 70s, some of the 3270 fullscreen editors got enhancements to save source file changes as "updates" (the original source file left unchanged ... and an "update" file was saved with control statements to modify the original source to what had been performed in the edit session). for random drift ... recent post mentioning some connection between the cms multi-level update work and internet domain name system http://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX misc. other recent posts mentioning cms source update processes http://www.garlic.com/~lynn/2007f.html#12 FBA rant http://www.garlic.com/~lynn/2007m.html#11 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007m.html#15 Patents, Copyrights, Profits, Flex and Hercules http://www.garlic.com/~lynn/2007n.html#3 Is Parallel Programming Just Too Hard? misc. recent posts about supporting unannounced 370 features under cp67: http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days? http://www.garlic.com/~lynn/2007f.html#12 FBA rant http://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What I miss in my OS Newsgroups: alt.folklore.computers Date: Sat, 30 Jun 2007 17:39:28 -0600 re: http://www.garlic.com/~lynn/2007n.html#32 What I miss in my OS for a slightly different take ... post in thread that ran in comp.databases.theory http://www.garlic.com/~lynn/2007n.html#30 How would a relational operating system look like? now this post touches on log structured filesystems http://www.garlic.com/~lynn/2007n.html#6 Is Parallel Programming Just Too Hard? ... but mentions that typically it refers to database type transaction logging of filesystem control information ... as opposed to always writting new/changed data to a new (physical) disk location (frequently also preserving unmodified records ... which then periodically requires "garbage collection" ... file reorganzations for things like contiguous/sequential). so one of the "post-relational" databases that did something similar was Illustra ... where changed/updated records always went to new disk location and allowed arbitrary older versions/views (various combinations of original records and some selected set of changed/modified records). Ilustra was bought up by Informix ... which was subsequently bought by IBM. Surviving web references seem to be mostly about Illustra object/relational paradigm ... and very little about the versioning methodology (which required periodic processes for "garbage collection" and deletion of unwanted versions) http://philip.greenspun.com/wtr/illustra-tips.html from above: Archiving One of Illustra's coolest sounding features is archiving. You get to query the system to find out what your data looked like, say, 6 months ago. I relied on this feature in a classified ad system. I would DELETE the ads from the table but still have them around when I wanted to calculate statistics on, say, how many users had successfully sold their goods because of the service. ... snip ... so if you leave/preserve the older versions ... then you also get archiving
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM obsoleting mainframe hardware Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Sat, 30 Jun 2007 18:09:50 -0600 Anne & Lynn Wheeler <lynn@garlic.com> writes: in fairly stable industry this worked since consumer tastes weren't signicantly changing. However the 8yr lag could become significant if there was any significant change in what the market place was looking for (giving vendors that had much shorter product cycle a competitive edge). re: http://www.garlic.com/~lynn/2007n.html#31 IBM obsoleting mainframe hardware of course, this could be considered another plug for cycling Boyd's OODA-loops faster. misc. past posts mentioning Boyd http://www.garlic.com/~lynn/subboyd.html#boyd and various URLs from around the web mentioning Boyd and/or OODA-loops http://www.garlic.com/~lynn/subboyd.html#boyd2
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: IBM obsoleting mainframe hardware Newsgroups: bit.listserv.ibm-main,alt.folklore.computers To: <ibm-main@bama.ua.edu> Date: Sun, 01 Jul 2007 10:46:45 -0600 chrismason@BELGACOM.NET (Chris Mason) writes: One of the presentations was someone from a big UK bank who defended IBM having made the 155 and 165 available and relatively shortly afterwards having announced the 158 and 168 - together with the relatively expensive DAT box extension to the 155 and 165. I hope I'm remembering the details about right. I heard about this only second-hand but I believe the argument was that IBM was right to offer the enhanced performance of the 155 and 165 as soon as it could in spite of the fact that it knew that the virtual storage models were well advanced in development. I guess there was a shadow of the "it's illegal to preannounce" principle hanging over this. re: http://www.garlic.com/~lynn/2007n.html#31 IBM obsoleting mainframe hardware http://www.garlic.com/~lynn/2007n.html#34 IBM obsoleting mainframe hardware 370/165 ... announce jun70 http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3165.html 370/168 ... announce aug72 http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3168.html for virtual memory ... hacking virtual memory support into MVT (for VS2/SVS) was needed in addition to the virtual memory hardware retrofitted to 165s (there were significant software as well as hardware schedules). this is similar to previous comments about crash program to try and get out 370-xa (after FS project was killed) and POK in 1976, convincing the corporation to shutdown vm370 product and transfer all the developers to POK as part of being able to make mvs/xa (software) schedule (although Endicott was eventually able to save part of the vm370 product mission). i've mentioned before about (370 virtual memory) prototype work that went on in pok, using 360/67s and hacking "single address space" virtual memory into the side of MVT ... as well as cobbling in cp67's (ccw translation) CCWTRAN into MVT ... i.e. cp67 had started out having to build "shadow" channel programs with real addresses ... for the virtual machine's channel programs; (in SVS) all the (MVT) channel programs passed via EXCP ... would be equivalent "virtual address" channel programs ... requiring similar translation (and misc. other things like page locking/pinning) recent posts about using CP67's CCWTRANS as part of turning MVT into os2/svs http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question The other part ... was that there was a lot of work to retrofit virtual memory to 165 ... so much so that they ran into schedule problems. In order to buy back six months in the 165 virtual memory schedule, there was an escalation dropping several features from the original 370 virtual memory architecture. Once the 165 engineers had won that battle, then all the other processors (that had already completed their virtual memory implementations) ... had to go back and remove the dropped features. recent posts mentioning 165-ii schedule issues and impact on dropping features from original 370 virtual memory architecture http://www.garlic.com/~lynn/2007f.html#7 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology http://www.garlic.com/~lynn/2007j.html#43 z/VM usability http://www.garlic.com/~lynn/2007k.html#28 IBM 360 Model 20 Questions
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How to flush data most efficiently from memory to disk when db checkpoint? Newsgroups: comp.os.linux.development.system,comp.databases.theory Date: Sun, 01 Jul 2007 11:18:02 -0600 Sune <sune_ahlgren@hotmail.com> writes: I'm looking into designing an in-memory DB and I wonder: How to flush data most efficiently when I checkpoint? Say I have a page size of 8K and 1K of those have been updated in random places, that is, the changes may be contiguous but most likely they are not. Will it always be more efficient to flush the whole page instead of keeping track of each element and write them to disk one by one? Obviously, if I did this I would flush them from page offset 0 to the end of the page, in that order. Sorry to bother you with such elementary questions but I want to get things right from the beginning, and other people's experiences are usually very helpful. some of this can be related to transactional memory ... there have been various past threads in comp.arch about both software & hardware transaction memory. early 801/risc (late 70s, early 80s) had support for hardware transactional memory ... it was used for journaled filesystem (JFS) in aixv3 on RIOS (i.e. power, rs/6000) ... basically all the (unix) filesystem metadata was laid out in memory area defined for transactional memory. wiki reference http://en.wikipedia.org/wiki/JFS_file_system there are granualarity trade-offs regarding having explicit log API ... and having explicit references to all changes or having to scan for all the actual changes. when palo alto started looking at porting jfs to platforms w/o transaction memory ... they found that they actually had better performance with the explicit log calls ... even compared to retrofitting to aixv3 running on rs/6000 (and not using the hardware transactional memory) references to software transactional memory http://en.wikipedia.org/wiki/Software_transactional_memory part of the transactional memory tends to also get tied up with parallelism and concurrency models a comp.arch thread (from google groups) http://groups.google.com/group/comp.arch/browse_thread/thread/5b0cb88a6d36b309/f5ad4a01cbed0a79?lnk=st&q=&rnum=12#f5ad4a01cbed0a79 intel article related to large number of cores http://www.intel.com/technology/magazine/computing/tera-scale-0606.htm
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: FastTCP Commercialized Into An FTP Appliance Newsgroups: comp.protocols.tcp-ip Date: Sun, 01 Jul 2007 14:10:52 -0600 FastTCP Commercialized Into An FTP Appliance http://hardware.slashdot.org/hardware/07/07/01/1718221.shtml Startup FastSoft Prepares App Accelerator http://www.eweek.com/article2/0,1759,2152807,00.asp?kc=EWRSS03119TX1K0000594 older threads on this subject: http://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!! http://www.garlic.com/~lynn/2003j.html#46 Fast TCP http://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband? http://www.garlic.com/~lynn/2004k.html#9 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#17 FAST TCP makes dialup faster than broadband? http://www.garlic.com/~lynn/2004k.html#18 FAST TCP makes dialup faster than broadband? http://www.garlic.com/~lynn/2004k.html#19 FAST TCP makes dialup faster than broadband?
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: alt.folklore.computers Date: Sun, 01 Jul 2007 15:15:21 -0600 greymaus writes: Now being supplented by `minidigger', tracked vehicle with just the digging arm, and without the loading bucket in front/back.. AFAIK, the U.S. version of the JCB is a bit more limited than the U.K. version. how 'bout ditch-witch, http://www.ditchwitch.com/ some history http://www.ditchwitch.com/dwcom/AboutUs/index.jsp they have trenchers that are about half the size of small car (they actually come in a variety of sizes). they are commingly used for underground utilities, propane gas lines, etc (i.e. bldg. codes typically have 500gal propane tanks quite a distance from nearest structure). one of the relatives had acquired one, there was big business installing 500gal propane tanks leading up to y2k.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Parallel Programming Just Too Hard? Newsgroups: alt.folklore.computers Date: Sun, 01 Jul 2007 19:06:43 -0600 re: http://www.garlic.com/~lynn/2007n.html#38 Is Parallel Programming Just Too Hard? the ditch-witch, a relative got, was tracked vehicle about the half the size of small automobile ... there was no place for the operator to ride, the operator walked along side the machine ... ditch-witch family company originated 1902 http://www.ditchwitch.com/ all the JCB stuff appears to be more traditional construction and agricultural equipment ... JCB family company originated 1945 http://www.jcb.com/ they all appear to have some sort of platform for the operator to ride. more like the small caterpillar stuff i.e. select "compact equipment" at: http://www.cat.com/ the stuff i grew up with was more traditional farm equipment, international harvestor (last tractor was 1985) and massey-furgeson http://www.masseyferguson.com/ i really learned to drive, summer i turned nine ... old yellow 38chevy(?) flatbed .... starter was pedel on the floor and there was no syncromesh ... all gear shifts required double clutch (or come to stop) and you had to acquire an ear for the correct engine speed... slightly related topic drift http://www.garlic.com/~lynn/2007m.html#18 Scholars needed to build a computer history bibliography before that i was just allowed to do some steering on small farm tractor.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Windows Monitor or CUSP? Newsgroups: alt.folklore.computers Date: Mon, 02 Jul 2007 06:32:11 -0600 jmfbahciv writes: All banking going on-line is inevitable. Which OS is going to be the default is still to be determined. At the moment, there are one and one-half choices of OS software for the regular user. The "one" is whatever MS shite is automatically installed on all systems. The one-half is a Unix-flavor and it takes an effort or the help of a friendly geek to get that software