Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Feb 2020 00:25:38 -0600
From:      Scott Bennett <bennett@sdf.org>
To:        johnl@iecc.com
Cc:        freebsd-questions@freebsd.org
Subject:   Re: terminology and history (was Re: Re  updating BIOS)
Message-ID:  <202002140625.01E6Pcej002541@sdf.org>
In-Reply-To: <20200212170420.2B9961450DF8@ary.qy>
References:  <20200212170420.2B9961450DF8@ary.qy>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
"John Levine" <johnl@iecc.com> wrote:

> In article <202002120724.01C7OcSW005991@sdf.org> you write:
> >that later virtual memory systems had.  Although offered by Cambridge University,
> >rather than IBM, CP-67/CMS provided virtual machine support.
>
> Uh, no, it was the IBM Cambridge Scientific Center in Cambridge MA.

     Thank you very much for that correction.  My memory there was probably
fuzzed because the information was of a much lower priority to my 18-year-old
mind at the time than other aspects of the system. ;-)

> It was in the same building where Project MAC was.  CP was a
> skunkworks project, originally on a modified 360/40, then on a /67.
> It was quite embarassing that CP/67 was so much faster and more
> reliable than the flagship TSS.  I used both; TSS would have been
> great if if worked, but it didn't.  It was also not surprising, since

     By the time we got to play with it, TSS certainly did work.  My impression
of it was deflated by its slowness and its operational problems.  We attributed
the slowness to a combination of real memory limitations and speeds of 2301 drums,
the latter being required devices for TSS as primary paging areas.  CP-67 could
get by with disk drives.  However, TSS was a big system in terms of capabilities
and in terms of code, which greatly exceeded those of any virtual machine setup,
as should be expected from the definitions of "operating system" and "virtual
machine facility".  CMS was a single-user operating system, fully capable of
running on bare metal (though it was a big waste of hardware to do that:-).

> CP was written by a small skilled staff while TSS had hordes of
> programmers trying to implement undebugged specs.

     The scopes of the problems to be solved were of different orders of
magnitude.  As already noted, one was an OS, and the other was a VM system.
>
> >>	[MS/PC/DR/Free]DOS was a lot more like a mainframe batch operating
> >
> >     No, that was my point.  They were all like monitor systems (e.g., IBM
> >1620/1710 Monitor I).  They did almost nothing for the user or program except
> >for loading an executable program from a disk drive and accepting a return of
> >control when the application program ended, ...
>
> They also provided a file system, which was pretty important.  I'd say they
> didn't provide quite as much as DOS/TOS but it was more than a batch monitor.
>
     IIRC(*), the System/7 had a primitive file system, though it did not have
a monitor.  It depended upon a connected System/360 or /370 to make it load a
program from the disk drive.  IOW, a file system need not be part of either a
monitor or an OS.

* This was in the early 1970s.  I disliked the System/7 I was assigned to work
with--imagine a system with no compare instruction, only subtract--and have made
no effort to maintain these memories.  My memory of details could well be
mistaken.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?202002140625.01E6Pcej002541>