The Perfect Computer - 36 bits?
|
From: jmfbahciv on 31 Mar 2007 07:41 In article <1ptr03dlr4i094g32r3aflhsg8e12ing85(a)4ax.com>, Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >On Thu, 29 Mar 07 13:29:12 GMT in alt.folklore.computers, >jmfbahciv(a)aol.com wrote: > >>In article <tl7n03h8uppujai6ck0ap794okqulb9i71(a)4ax.com>, >> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >>>fOn Wed, 28 Mar 07 11:16:23 GMT in alt.folklore.computers, >>>jmfbahciv(a)aol.com wrote: >>> >>>>In article <46099974$0$18859$4c368faf(a)roadrunner.com>, >>>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >>>>>jmfbahciv(a)aol.com wrote: >>>>>> >>>>>> And I'm telling you, again, that DEC did not have the infrastructure >>>>>> to handle that support. DEC's main business was not retail-ish. >>>>>> >>>>> >>>>>Even IBM decided they didn't want to be in this business. >>>> >>>>I've spent quite a bit of my thinking time trying to figure out >>>>how to do the single task of software support with 200 million >>>>systems. I still don't have it. Micshit is trying by using the >>>>internet and edictive practices. That's not working either. >>>> >>>>Number one rule is to not ship security holes and have a backout >>>>plan when you do. >>>> >>>>I haven't thought of any way to do this. Micshit's answer is an >>>>"as is" which was anathema to the manufacturers of the past. >>> >>>Ahem, manufacturers didn't do software support: they did production and >>>maintenance. >> >><ahem> But DEC did do software support for the products it did >>ship. This was part of our corporate folklore. It would ahve >>been unthinkable to sell millions of _systems_ with no followup. >>It simply was not in our blood to do this. If the customers >>wanted us to leave them alone, we did. However, the reverse >>was never true. >> >>>A few inhouse staff did the software support, complained to the >>>manufacturer occasionally, mostly got some response, rarely got changes >>>made, if it followed the strategic direction (on the mini products). >>>The same model would have worked for personal workstations, with the >>>customer being responsible for most support. >> >>That implies that all sources are shipped with the toy. You >>people are talking about a product line that made acquiring sources >>a miracle. > >DEC did not ship sources for their popular PDP-11 OSes, Since when? > we had to work >with the documented system interfaces, but they were pretty good for >most purposes. > >>>DEC FE supported their terminals >> >>Terminals did not run OSes. We knew how do hardware in that >>number but not systems. Do you understand the difference >>between a piece of gear and a _system_? > >Do you understnad the difference between supporting hundreds of >mainframe systems on a few hardware bases and thousands of mini systems >on a variety of hardware bases? Do you understand that support a PC base would have been giving direct corporate support to each and every person who had accounts on the mainframes? Not only would we have to "train" all users to be sysadmins, but they would also have to be trained to be field service, operator, systems analyst, etc. >IMHO the mini people really had to have had their ducks in a row to deal >with the volume. >Remember there were independent industry mags for at least some of the >popular mini OSes. This has nothing to do with supporting the _systems_ that we sold. /BAH
From: jmfbahciv on 31 Mar 2007 08:13 In article <tlvr03lc4tta7uc53787pi8aa0gc4ikdpm(a)4ax.com>, Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >On Fri, 30 Mar 07 12:12:22 GMT in alt.folklore.computers, >jmfbahciv(a)aol.com wrote: > >>In article <573r7kF2arf8qU1(a)mid.individual.net>, >> =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >>>> OK, then my question goes back to Jan and Barb. Why was a full sysgen >>>> required or recommended for the situations you guys were talking about? >>>> Wouldn't partial gens do the job without the need for the large >>>> resource commitment Jan talked about? >>> >>>At least for the first 10 years or so, VAX/VMS wasn't structured in a >>>sufficiently loose way to make this feasible, IMO - we're talking the core of >>>the OS here, >> >>Yes, I'm talking about that, too. >> >>> of course, not all of the utilities etc. that constitute the bulk >>>of the code. However, if you needed to make an interface change at the >>syscall >>>level, you'd need to recompile everything. >> >>Really? Most of TOPS-10's rebuilds had to do with hardware changing, >>not software. Oh, I see. ARe you talking about adding a new >>syscall? That would be a new feature; it's safer to do a complete >>rebuild, especially if the syscall had anything to do with disk >>I/O user-mode code interfaces. >> >> >>> >>>And anyway, I can't think of a problem that would have required a rebuild. >>>Significantly upgrading a subsystem, like the batch or print job management, >> >>Nah, on the -10 that was at the app level. >> >>>would have been much easier with the source - but as I said, DEC customers >>>never considered such things until (too) late, in contrast to IBM's >>customers. >> >>Our device tables, command tables, and all fields associated with them >>were generated by macros based on the questions answered at MONGEN >>time (a program that queried the sysmanger what hardware and software >>features he wanted to put on his computer system). The best >>way to make any changes to those would be to do it the "right way". >>Fumble fingers can destroy machines. > >Without the sources, you'd just dump the tables, define your own macros >to create the entries, and add new entries to the tables; find where the >table origins were loaded, and patch the code to load the new origins. And now you've just overwritten code. In the biz, it's called buffer overflow. /BAH
From: jmfbahciv on 31 Mar 2007 08:16 In article <574n10F2bn1okU1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >Of course not - see my other post. > >I don't suffer from VMS arrogance - I worked for several years on a dual >PDP-10 system, some of it in parallel with a 780, both serving a whole physics >institute (about 150 users). I know what was (or is) good and bad about these >two systems. _You_ are suffering from PDP-10 nostalgia. Not really. You are talking from the outside in. You never saw how we made stuff. You assume that your methods of development would work in our company. I can assure that they would not. They would if your site had been our only customer. > >>>>>And anyway, I can't think of a problem that would have required a rebuild. >>>>>Significantly upgrading a subsystem, like the batch or print job management, >>>>Nah, on the -10 that was at the app level. >>>Sure, but it needed some monitor support, didn't it? >> Not after we shipped V1.0. Sites did not have to put up a new monitor >> just to put up a new distribution of these subsystems. > >I said significantly upgrading, not a new distribution. > >> YOur definition of reboot and my defintion of reboot is two completely >> different things. Our customers expected a reboot to take a few >> minutes, at the _most_. > >Not at all. Just a more intelligent reboot. Again, that depended on what problems you were solving. /BAH
From: jmfbahciv on 31 Mar 2007 08:20 In article <460DDFA3.6591A8E9(a)yahoo.com>, CBFalconer <cbfalconer(a)yahoo.com> wrote: >jmfbahciv(a)aol.com wrote: >> CBFalconer <cbfalconer(a)yahoo.com> wrote: >>> jmfbahciv(a)aol.com wrote: >>>> >>>.... snip ... >>>> >>>> Neither would matter. Look if you increase your "CPU speed" by >>>> twice, your system will then be constantly waiting on I/O becaues >>>> the CPU got its job done faster. YOur system software and usage >>>> had been tweaked over the years to accomodate the behaviour of a >>>> VAX with its peripherals (this includes memory). Now you replace >>>> the CENTRAL processing unit with something that goes twice as fast. >>> >>> And the system simply switches to another process while waiting for >>> i/o. No problem. >> >> It is a problem because the monitor has run every job that was >> runnable and _all_ are now waiting on I/O to complete. Look. >> We saw this. It was part of our business cycle. Systems were >> I/O bound so we built a faster I/O. The same jobs were now >> CPU bound so we built a faster CPU. The same jobs were now >> I/O bound so we built a faster I/O..... > >You simply go to IL [1] for your logic modules, and to FTL [2] for >your disk drives. :-) > >[1] Instantaneous Ltd. >[2] Faster Than Light Inc. > <GRIN> I'll leave that all as an exercise for the kiddies. I'm in the habit of working on the real problems, mostly the mess prevention parts of those problems. /BAH
From: jmfbahciv on 31 Mar 2007 08:29
In article <mddejn6wjk5.fsf(a)panix5.panix.com>, Rich Alderson <news(a)alderson.users.panix.com> wrote: >jmfbahciv(a)aol.com writes: > >> In article <mddd52rx59j.fsf(a)panix5.panix.com>, >> Rich Alderson <news(a)alderson.users.panix.com> wrote: > >>> They wanted 8-bit bytes and power-of-2 words, and nothing was going to >>> change their minds about that. > >> Then customers would continue to buy -11s and move the boring grunt work to >> the -10s and their secretaries. > >I see that the point was completely missed, and >there's no use in trying to fix it. It was not missed by me. Those people you talked to will continue to have their minis bought for them. However, the infrastruture that surrounded them would have computing needs beyond mini capabilities. Thus, the _bosses_ of those people you talked to would buy a -10 because 1. they were already doing business with DEC and were pleased with the services; 2. it was easier to stay with one supplier than introduce a brand new computer culture 3. the -10 was "compatible" with the gear that those people to whom you talked insisted on using. Now do you see? /BAH |