The Perfect Computer - 36 bits?
|
From: Jan Vorbrüggen on 30 Mar 2007 08:37 > VMS and Tru64 users have long since learned that published roadmaps are not > worth the paper you would waste printing them out. Alpha users, yes. VMS - why would you say that? Oh, you mean you had to "migrate" to a new processor? So what - everytime you "upgrade" a Microsoft OS, you need to move to a new processor, and there's not much help in keeping your existing data in a useable state, because the "upgrade" is mostly "install and copy". Jan
From: Jan Vorbrüggen on 30 Mar 2007 08:39 > Really? Most of TOPS-10's rebuilds had to do with hardware changing, > not software. That's just a reboot, in almost all cases. >>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? > 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. Definitely. But there's no need to rebuild everything: just do the sizing during reboot. Jan
From: jmfbahciv on 30 Mar 2007 08:38 In article <574edpF2bg1n6U1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >> An example where a rebuild would be necessary is if the original >> build goofed the MONGEN (that was the questionaire the monitor >> used to determine which hardware devices, tables (lengths) etc. >> would be on the system it was supposed to run. > >Just reboot. Nope. If you don't have the software, you have to a rebuild. > >> Another reason would have been if a table or list was too short >> and extending it via patching would create more problems. It >> would be a more controlled experiment if the list were extended >> via a rebuild rather than patching. > >Just reboot. Nope. YOu keep assuming that all tables were extensible. I'll guarantee you they were not. > >> PS. Extending fields would be a better reason for a rebuild. > >Agreed. > >> Another reason to do a build would be to incorporate the thousands >> "patches" you had done to make sure that all would work as >> coded in the sources. That way you can resume your debugging >> and testing with a monitor that you know has all fixes set in >> ASCII bits. This was one of the most important steps in our >> source maintenance procedures. > >That's why the VMS guys do their nightly build. No reason for a customer to do >that. Of course a customer would to that IF the customer had sources and was implementing its own device or channel or bus. One of the reasons customers loved PDP-10s is because they could add their own home-grown software and hardware. With the advent of the VMS/VAX replacement, DEC^WDigital sent the message to _all_ their customers that customers were too stupid to do any of their own system work. /BAH /BAH
From: Charlton Wilbur on 30 Mar 2007 08:47 >>>>> "BAH" == jmfbahciv <jmfbahciv(a)aol.com> writes: >> With PCs the user companies set up their own support teams. BAH> Wrong. Companies don't do this? Oddly enough, BAH, there's a person employed by the company I work for whose *sole* job it is to keep the Windows machines running. And I see frequent jobs for "system administrators" -- people whose task it is to keep the Unix machines running -- and "help desk operators" -- people whose task it is to field internal questions. Are you telling me that your average office worker, when he has a problem with his PC, calls Microsoft? >> Windows needs more support people than Unix. BAH> Wrong. Not borne out by several TCO studies or by the experiences of anyone who's worked in a mixed environment. Charlton -- Charlton Wilbur cwilbur(a)chromatico.net
From: jmfbahciv on 30 Mar 2007 08:42
In article <574eopF2bg1n6U3(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >> Really? Most of TOPS-10's rebuilds had to do with hardware changing, >> not software. > >That's just a reboot, in almost all cases. You are suffering from VMS arrogance; you keep assuming that the only hardware in the world was that which was supplied by VMS development group. It was not. There were other hardware out in the world; it usually had logos of IBM, Sun, Prime, Dumfuck, KFC, etc. > >>>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. > >> 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. > >Definitely. But there's no need to rebuild everything: just do the sizing >during reboot. 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_. /BAH |