[TUHS] 32V memory management: not quite V7 style swapping -- source code update

Greg A. Woods woods at robohack.ca
Tue Jun 8 05:24:43 AEST 2021


At Sun, 6 Jun 2021 14:23:49 -0400, Clem Cole <clemc at ccc.com> wrote:
Subject: Re: [TUHS] 32V memory management: not quite V7 style swapping -- source code update
>
> You got me thinking and I'm curious if anyone really knows historically how
> many sites ran a 32V system?   In those days (late 70s/early 80s) the
> universities that knew and and even many sites inside the Bell System, the
> Vaxen I ran 4.1BSD (say the Marx's brothers at Whippany along with the Vax
> in the underseas research lab were we put the AP I did for my thesis).

If my memory serves me correctly, University of Calgary ran 32V on their
first teaching VAX 11/780 for a short while when I was starting my
second year of undergrad (Sept. through to the xmas break, IIRC).  This
would be the fall of 1980.

After that first term I think it was running 3BSD for the rest of the
semester, and finally was running and early 4BSD not long after.

As I recall they had tried to run 3.x right away but had some problems
(possibly with a serial driver?  the initial setup had some 20 or 30
terminals) and in order to not have all us students trying to crowd onto
the old PDP 11/60 with just 12 terminals (which was also still in use by
a bunch of classes), while the VAX sat idle, they just gave up and
(re)installed 32V.  I think my class probably lost a week or two of time
to use the system.  At that time the only other teaching system was the
Multics mainframe, and it was also overloaded with too many users.

I remember being a little dismayed that the BSD C compiler seemed
entirely different from 32V (where it was very V7-like and thus what I
was familiar with from first year).  It wasn't until 4BSD offered me job
control and command history in CSH that I finally became more accepting
of BSD.

I think it was after the 4.x upgrade that they instituted CPU time
limits for students, and I remember discovering that if one caught
SIGXCPU then the limit just kept increasing -- i.e. the hard limit never
worked in the initial release of whatever version it was -- so I wrote a
little program that would catch the signal, then burn CPU in a loop
until the limit was above some requested value, and then it would fork a
shell.  I put that in my ~/.login and had lots of fun until I was
caught.  Then I fessed up and didn't get expelled!  They fixed the bug
of course and as a result of it all I then got to know the sysadmins
better and learned an awful lot more from them than I did in class on
some/many days.

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210607/ac7c76be/attachment.sig>


More information about the TUHS mailing list