The Perfect Computer - 36 bits?
|
From: Nick Maclaren on 28 Mar 2007 09:28 In article <56v8c9F2atcpcU1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> writes: |> jmfbahciv(a)aol.com schrieb: |> > |> > Microfiche is NOT machine-readable sources. With machine-readable |> > sources, DDT and TECO a customer could bandage most problems until |> > the real fixes got in. |> |> Bah. In this case, diagnosis is more than half the cure, and for diagnosis, |> the microfiche is more than good enough. And with PATCH (in DDT's place), I |> fixed several of such cases on the fly, source or no source. ... That is exaggerating. For 90% of diagnosis, it is. For 10%, one may need to do a whole-source search or may need to create an instrumented version to trap the error. Regards, Nick Maclaren.
From: Andrew Swallow on 28 Mar 2007 09:30 jmfbahciv(a)aol.com wrote: > In article <n8WdnY8v4J21yJfbRVnyhQA(a)bt.com>, > Andrew Swallow <am.swallow(a)btopenworld.com> wrote: >> jmfbahciv(a)aol.com wrote: [snip] >>>> DEC sold to the technical part of companies - so the salesmen, >>>> warehouses and trucks needed in the first year existed. >>> I am not talking about gear movements. I am talking about >>> the infrastructure that exists to support computer systems. >>> This is hardware maintenance, software maintenance, etc. >>> You keep seeing this business through Micshit distribution >>> glasses. There more to software than that. >> That infrastructure was all there to support the PDPs and VAXes. >> >> Sloth is not an excuse. > > Now do a head count. It had nothing to do with sloth. It had > everything to do with the fact that a day was only 24 hours > long and each problem would take at least 5 minutes just say > hello and how's the kids introductions. > > Now. DTFM. Assume one billion machines. > > /BAH That is lots of lovely training courses for us to take and give. There is initially a higher learning curve but the reduction in bugs causes a lower long term support level. Andrew Swallow
From: Jan Vorbrüggen on 28 Mar 2007 09:37 > |> Bah. In this case, diagnosis is more than half the cure, and for diagnosis, > |> the microfiche is more than good enough. And with PATCH (in DDT's place), I > |> fixed several of such cases on the fly, source or no source. ... > > That is exaggerating. For 90% of diagnosis, it is. For 10%, one may > need to do a whole-source search or may need to create an instrumented > version to trap the error. I don't think the search would have helped much. Instrumenting - yes, but that ability was there from the start, and later versions were actually pretty good, and I remember using it to diagnose an obscure filesystem error. Jan
From: Nick Maclaren on 28 Mar 2007 09:46 In article <56v9bvF2b1butU1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> writes: |> |> > |> Bah. In this case, diagnosis is more than half the cure, and for diagnosis, |> > |> the microfiche is more than good enough. And with PATCH (in DDT's place), I |> > |> fixed several of such cases on the fly, source or no source. ... |> > |> > That is exaggerating. For 90% of diagnosis, it is. For 10%, one may |> > need to do a whole-source search or may need to create an instrumented |> > version to trap the error. |> |> I don't think the search would have helped much. Instrumenting - yes, but that |> ability was there from the start, and later versions were actually pretty |> good, and I remember using it to diagnose an obscure filesystem error. It may not have helped you, but there have been a lot of occasions in which I have needed to know where something might have been updated NOT in the main modules. And there were a zillion reads and loads of the address :-( Regards, Nick Maclaren.
From: Anne & Lynn Wheeler on 28 Mar 2007 10:08
nmm1(a)cus.cam.ac.uk (Nick Maclaren) writes: > I know. My point stands. While it is an over-simplification, the > Series-1 was very much an SNA engine, and lived or died with that. > Despite IBM's belief, SNA never made much headway into the scientific > markets, and didn't make as much even in the commercial ones as they > claimed. I can't remember if the Series-1 ever did support the 'X.' > protocols, but it may have done (probably too little, too late). re: http://www.garlic.com/~lynn/2007f.html#79 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007g.html#1 The Perfect Computer - 36 bits? official system for series/1 was RPS ... quite heavyweight ... there were jokes that some of the people that transferred from Kingston to Boca were trying to re-invent OS/360 MFT. EDX was much more lightweight system coming out of research physicists for doing instrument automation. no sna orientation. the closest that it might have to sna ... was a very early (actually pre sna) battle to try and get the series/1 (peachtree) engine used for 3705 controllers (peachtree was much more capable processor than what actually got selected for 3705). yale iup was pure (full-duplex) ascii terminal emulation going into mainframe ... with no hint of sna. one of the target margets was mainframe unix. the palo alto science center also first did port of UCLA's Locus to some 68000 processors and series/1. Later Locus was ported to mainframe and PS2s ... and sold as aix/360 and aix/ps2. recent series/1 post with wiki reference that talks about use for GM manufactoring (i have vaque recollection of something called MAP protocol?) and extensive deployment by the Marines (whoever did the wiki articile must have been one of those datadinks?) http://www.garlic.com/~lynn/2007f.html#42 Is computer history taught now? quicky search engine use turned up http://www.gcom.com/home/company/custpers.html .... from above What does a person do after working on one of the most exciting and successful university-based computer projects ever? That was the question confronting Dave Grothe back in 1979. Dave had been a systems programmer on the immensely successful ILLIAC IV computer project at the University of Illinois. .... Gcom's first customer, another small company located in Santa Barbara, CA, built a Z80-based protocol processor card for the IBM Series/1 minicomputer. Gcom provided an X.25 protocol stack for this board. IBM liked this product so much that it adopted it and put it into its catalog. IBM's first customer for the X.25 adapter was MasterCard. .... snip ... Mastercard had large number of series/1 driving large x.25 network (for all i know still does ... although i assume that they've since moved on to various PC platforms). |