From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28517 invoked from network); 9 Mar 2023 23:26:08 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 9 Mar 2023 23:26:08 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 0BC3F41349; Fri, 10 Mar 2023 09:26:06 +1000 (AEST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by minnie.tuhs.org (Postfix) with ESMTPS id E7D954132A for ; Fri, 10 Mar 2023 09:25:58 +1000 (AEST) Received: by mail-vs1-xe34.google.com with SMTP id f23so3116766vsa.13 for ; Thu, 09 Mar 2023 15:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1678404358; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Xd+sJl8F3fqqJshW3qSWJvZ1m9976rCy5A30SqtD9D8=; b=Pz3Yc4E2VlVbgVYYZZGhIidS68XvztTXOLZ+Dr3D8vTOH2jxu2YBhWWnR42w7jFO/v xMwfYjc9NOoRboS4qwGwTXTGag0H1c3HuU8uwdYiJY8Ul538sAl3oFwL14RGXADSKLFQ ejCgxYwOnUYfla4EmAcWKDdWqkUuQLqVRc7OE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678404358; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Xd+sJl8F3fqqJshW3qSWJvZ1m9976rCy5A30SqtD9D8=; b=qh1tQOEyfSNqU5YDSYBfIoAwJgF1h2X49CmK5sm5g9nbUv6Oln++xFNsf568DCZ8sE 3nhIxEVJpaecQVMRQ9kwxyKBXorz6emKtZ40WnUDmo3+dSiN4F5PGq2Bjk1g3OBL8eG/ W8xm7N1ik7s6QryULY/FURa+rOnbPHXf52wKPyo8KFs688ZXAGOOTtmY5lp5FFmrCmZv oe7+sU1hptvFxzxu7xoGshQGLRNHzTjlflAk5ZBzVes0RTds89BjV5KiWNThS2JpGwEd CamzJaa6DgVwGJAm6D1Ez9aognGYNSw1uFdACbRS06DfxYZqXSAbNNeVkARzODv6wVQF NFgw== X-Gm-Message-State: AO0yUKXsfXaZ46r0xD6KoE/ywf9EWpYe9zUakx1pbEKUjBisTYV89WHp ihhmYCs49uAZMhvNC/7GaKZnV5h8JZAAVzxQpmwjx2dkD+gAonby7t9AIw== X-Google-Smtp-Source: AK7set+ptgJJGdAolohCZft3lJEB5x5X3+jKINH6rmDsd+g8OMtdWKnsf2m/gSJXDA13uroPVqH3AH366emIDtj2Gd4= X-Received: by 2002:a67:f349:0:b0:41f:641c:f775 with SMTP id p9-20020a67f349000000b0041f641cf775mr16092545vsm.3.1678404357851; Thu, 09 Mar 2023 15:25:57 -0800 (PST) MIME-Version: 1.0 References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> In-Reply-To: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> From: Clem Cole Date: Thu, 9 Mar 2023 18:25:32 -0500 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="0000000000008a225005f67ff714" Message-ID-Hash: DWSLICVMZUYXZOWT25S2OFISCEFHYWFU X-Message-ID-Hash: DWSLICVMZUYXZOWT25S2OFISCEFHYWFU X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: 'Huge' file support removed from PWB1 List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000008a225005f67ff714 Content-Type: text/plain; charset="UTF-8" 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 ;-) --0000000000008a225005f67ff714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I talked with John Mashey this PM and asked him about t= he huge file stuff and PWB1.

First, he did not remembe= r that they had done that, but ...=C2=A0=C2=A0

He then= emphasized that the=C2=A0PWB team was running the first (and for a long ti= me the largest) "computer center" using UNIX in the Bell System i= n Piscataway - supporting over 1000 programmers as a front=C2=A0end to the = mainframes. His memory is that they mostly used 88=C2=A0Mbyte RP04s [rememb= er, at the time, RK05s were only 2.5M].=C2=A0 Needing to support=C2=A0a meg= abyte or larger file would have been relatively=C2=A0rare for them.=C2=A0 H= e also pointed out they needed to run their system on=C2=A0systems as small= as 48K byte 11/40s to as large as 1M 11/70s.

As he s= aid, his team tried to track Dennis and Ken's Research system=C2=A0clos= ely since the=C2=A0PWB team was not primarily in the system development/enh= ancement business - i.e. they tied to keep what would become PWB1 an= d whatever was running at Research as similar as they could [he told some s= tories about running to MH to get Dennis' latest compiler binary becaus= e the incremental development scheme dmr used would make someone like PWB t= hat took snapshots at different times, end up with a compiler that could no= t compile itself --#1#]. But the PWB group >> was << interested= in making the system they were running as reliable as possible and, more i= mportantly, being as graceful as possible when different resources were exh= austed.

He said it would have made sense for them = to remove the "huge file" support to help to defend against runni= ng=C2=A0out of space and the system having issues [V6 was extremely ungrate= ful about that condition]. So limiting file=C2=A0size=C2=A0became=C2=A0a si= mple quota, if you will. A runaway program was less likely to take the syst= em out. So the=C2=A0process would die because the file got too large (or, t= o use the IBM shop term in those days -- ABEND).


<= /div>
#1# He also regaled=C2=A0a bit about Ken's infamous Turning Awa= rd hack and discovering symbols in the compiler binary they could not under= stand ;-)
--0000000000008a225005f67ff714--