From: Rich Alderson on
Jan Vorbr�ggen <jvorbrueggen(a)not-mediasec.de> writes:

>> And some of that work was done by JMF, the other half of my username. It
>> took those with TOPS-10 experience to cause VMS to evolve to be an OS that
>> was useful. (The work wasn't jsut JMF's but the whole contingent of PDP-10
>> developers who moved to the 32-bit world after the 36-bits were cancelled.)

> The distinguishing feature of VMS, IMNSHO, is the VMScluster, with the
> connection manager and the lock manager as the main supporting pieces of
> software of that capability. TOPS-10 or -20 never had anything like it.
> Where was Leslie Lamport before this happened? (A lot of the VMScluster stuff
> is based on his ideas.)

Oh? That would come as a surprise to the students at LOTS after 1984, when we
clustered the three 2065s, and eventually the Systems Concepts SC-30M, on the
CI bus that came with the HSC-50s and RA-81 disks (all invented, BTW, for the
36-bit Jupiter). Cross-system resource sharing, central login (a Stanford
innovation that was taken back by DEC^WDigital for Tops-20 v6.1), and so on.

> Enterprise-level batch and print management, for instance, I can well believe
> was derived from, in particular, TOPS-20 - TOPS-10 was better than early
> versions of VMS in this respect, but VMS caught up after some time.

In point of fact, at one time the Operator Command Processor OPR shared a
manual among the three operating systems--and it didn't originate in VMS.

--
Rich Alderson | /"\ ASCII ribbon |
news(a)alderson.users.panix.com | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
From: Rich Alderson on
Stephen Fuld <S.Fuld(a)PleaseRemove.att.net> writes:

> jmfbahciv(a)aol.com wrote:
> > In article <571ro8F2bdosvU1(a)mid.individual.net>,
> > =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote:
> >>> Only for small problems. What do you do in the cases where a
> >>> reassembly is the way to make the problem go away?
> >> Do a complete SYSGEN?
> >
> > Yes.
>
>
> Was there no alternative between patching the object code and doing a
> complete sysgen? On the system with which I am most familiar (Non-DEC),
> we mostly did partial sysgens where only a small number of modules were
> re-assembled and the system linked. Out of say 400 modules in the OS, a
> typical gen might assemble half a dozen and a large one perhaps a
> hundred. We did full gens (all elements), very rarely.

A quick look at http://pdp-10.trailing-edge.com says that the Tops-20 V7.0
sources involve 165 files, not all of which are going to be Macro-20 source
(Link-20 control files, batch jobs, etc.); Tops-10 v7.04 similarly involves
181 files.

In porting Tops-20 to the XKL Toad-1, as well as implementing changes at
Stanford, we frequently re-compiled individual files, or perhaps a half dozen
or so for a major change, and re-linked against the previous builds' .REL
files. I can't speak to Tops-10 development--my involvement with that OS only
began 4 years ago with a new job.

--
Rich Alderson | /"\ ASCII ribbon |
news(a)alderson.users.panix.com | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
From: Toon Moene on
Jan Vorbr�ggen wrote:

> > Not having source *or* fiche made me very nervous.
>
> Ah yes, and now think about all those business- and safety-critical
> customers of the Microsoft operating systems...
>
> Jan
>
> PS: For those OSes, quite likely even having the source wouldn't help
> you much...

I seem to recall that Microsoft was telling the European Community's
competition court that the source *was* the documentation.

--
Toon Moene - e-mail: toon(a)moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Who's working on GNU Fortran:
http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
From: Rich Alderson on
Jan Vorbr�ggen <jvorbrueggen(a)not-mediasec.de> writes:

>> DEC had no plans to produce bigger VAX systems in the early 80s, and
>> peripherals were same as 11 range, so commercial non-compute
>> price/performance and expandability were non-competitive.

> Yes, that's the issue where I see the -10/-20 crowd have a valid point: the
> 8650 took much too long to arrive.

First they had to figure out how to erase the 4 extra bits.

>> HP may still be supporting OpenVMS on Itanics.

> They do, and VMS is still being actively developed.

True.

> AFAIK, even the Alpha is not only being supported but being actively
> developed.

BWAH-HA-HA-HA! You should go find a good archive of comp.os.vms and read it.

> Even VAX/VMS was being updated, not just supported, just a few years ago. A
> significant number of people a running VMS virtual machines on their PCs
> because they never ported their applications to something else. It seems
> likely that these VMs are the fastest VAXen ever built 8-).

Yes, they seem to have stopped OpenVMS/VAX development with v8.

--
Rich Alderson | /"\ ASCII ribbon |
news(a)alderson.users.panix.com | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
From: Anne & Lynn Wheeler on

krw <krw(a)att.bizzzz> writes:
> No system final test was being "outsourced" to anyone. The '70s were
> dire times for IBM. I've been told they were as bad as the early
> '90s, but covered it somewhat better.

at least some of which might be considered still attempting to recover
from the side-trip into future system project. i had been told that if
it had been any other company that dumped that much money down such a
hole (as went into FS), they would have gone under ... aside from the
issue of lost time and having to scramble to get back into the game.
numerous past posts mentioning FS
http://www.garlic.com/~lynn/subtopic.html#futuresys