The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: 'Huge' file support removed from PWB1
Date: Thu, 9 Mar 2023 18:25:32 -0500	[thread overview]
Message-ID: <CAC20D2MueHO_Oa=Jezkbq3pE4ndgSqoLH=DoFgj-stE823fPmw@mail.gmail.com> (raw)
In-Reply-To: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu>

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

I talked with John Mashey this PM and asked him about the huge file stuff
and PWB1.

First, he did not remember that they had done that, but ...

He then emphasized that the PWB team was running the first (and for a long
time the largest) "computer center" using UNIX in the Bell System in
Piscataway - supporting over 1000 programmers as a front end to the
mainframes. His memory is that they mostly used 88 Mbyte RP04s [remember,
at the time, RK05s were only 2.5M].  Needing to support a megabyte or
larger file would have been relatively rare for them.  He also pointed out
they needed to run their system on systems as small as 48K byte 11/40s to
as large as 1M 11/70s.

As he said, his team tried to track Dennis and Ken's Research
system closely since the PWB team was not primarily in the system
development/enhancement business -* i.e.* they tied to keep what would
become PWB1 and whatever was running at Research as similar as they could
[he told some stories about running to MH to get Dennis' latest compiler
binary because the incremental development scheme dmr used would make
someone like PWB that took snapshots at different times, end up with a
compiler that could not compile itself --#1#]. But the PWB group >> was <<
interested in making the system they were running as reliable as possible
and, more importantly, being as graceful as possible when different
resources were exhausted.

He said it would have made sense for them to remove the "huge file" support
to help to defend against running out of space and the system having issues
[V6 was extremely ungrateful about that condition]. So limiting
file size became a simple quota, if you will. A runaway program was less
likely to take the system out. So the process would die because the file
got too large (or, to use the IBM shop term in those days -- ABEND).


#1# He also regaled a bit about Ken's infamous Turning Award hack and
discovering symbols in the compiler binary they could not understand ;-)

[-- Attachment #2: Type: text/html, Size: 3050 bytes --]

      parent reply	other threads:[~2023-03-09 23:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 13:10 [TUHS] " Noel Chiappa
2023-03-09  8:21 ` [TUHS] " Kenneth Goodwin
2023-03-09 12:40   ` Jonathan Gray
2023-03-09 15:07   ` Ron Natalie
2023-03-09 15:13     ` Ron Natalie
2023-03-09 17:35     ` arnold
2023-03-09 17:01 ` Tom Ivar Helbekkmo via TUHS
2023-03-09 23:25 ` Clem Cole [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2MueHO_Oa=Jezkbq3pE4ndgSqoLH=DoFgj-stE823fPmw@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).