From tuhs at tuhs.org  Mon May  4 05:59:50 2026
From: tuhs at tuhs.org (ron minnich via TUHS)
Date: Sun, 3 May 2026 12:59:50 -0700
Subject: [TUHS] quick question on PDP-11 addressing
Message-ID: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>

I was re-reading the KT-11 docs, and got somewhat confused, and wanted
to verify my memory, that (absent Split I&D) user programs had virtual
addresses in the range 0-0xffff, and kernels the same: 0-0xffff.

Thanks, I know this has been discussed before, but I'm giving a talk
at IWP9 next week and want to make sure I'm not missing something. The
KT-11 doc left me uncertain.

You gotta love those old DEC docs, complete with SSI logic diagrams ...

From tuhs at tuhs.org  Mon May  4 06:33:24 2026
From: tuhs at tuhs.org (John Levine via TUHS)
Date: 3 May 2026 16:33:24 -0400
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
Message-ID: <20260503203324.B64EC107B7BB2@ary.qy>

It appears that ron minnich via TUHS <rminnich at gmail.com> said:
>I was re-reading the KT-11 docs, and got somewhat confused, and wanted
>to verify my memory, that (absent Split I&D) user programs had virtual
>addresses in the range 0-0xffff, and kernels the same: 0-0xffff.

Yes. All PDP-11's were 16 bit machines and the addresses generated by programs
were 16 bits. We used octai so it was 0 to 0177777.

Different models had more or less elaborate schemes to map the 16 bit program
addresses into 18 or 22 bit physical addresses. Some models had two modes, user
and kernel, some had three, user, supervisor and kernel, with separate I and D
addressing in each.

For each of the two or six virtual address spaces there was an eight-entry map that
mapped 8K pages of program addresses to 8K pages of physical memory.  Unix systems
as far as I know always treated user programs as a single chunk, or with I/D a single
sharable chunk of I and another chunk of D.

Bonus kludgery: Unibus addresses were 18 bits so on 22 bit systems (11/44 and /70)
there was another address map from Unibus to physical memory for DMA devices.

R's,
John

From tuhs at tuhs.org  Mon May  4 06:35:26 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Sun, 3 May 2026 16:35:26 -0400
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
Message-ID: <CAC20D2OCnfohCbpA=xOG18UmJcAeAXknSfmeYV_bsOEphp0gig@mail.gmail.com>

below

On Sun, May 3, 2026 at 4:00 PM ron minnich via TUHS <tuhs at tuhs.org> wrote:

> I was re-reading the KT-11 docs,

A PDP-11 has 16-bit registers, so all addressing must be within a 64K
boundary.

There are a few versions of the MMU

   - KS11 [CSS option for 11/20 -
   http://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option]
   - KT-11B [CSS option https://gunkies.org/wiki/KT11-B_Technical_Manual ]
   - KT-11C,CD  for the 11/45 class [45, 50, 55) [
   https://bitsavers.trailing-edge.com/pdf/dec/pdp11/1145/EK-KT11C-MM-005-KT11-C_CD_Memory_Management_Maintenance_Manual_1976.pdf
   ]\
   - For the 11/70, the MMU is builtin and the PARs are SW compatible with
   KT-11-C
   - and the KT-11D for the 40 class [40, 35]
   https://gunkies.org/wiki/KT11-D_Memory_Management_Unit
   - later 40 class processors (34, 34A and 60) use the KT-11A which is
   software compatible with the KT-11D

In all cases, regardless of operation mode (user, supervisor, kernel), the
CPU has a 16-bit address (virtual) space of 32K words (64K bytes).  The MMU
then maps those 16 bits into either an 18 or 22-bit physical address
space.  On a 40-class processor, that means a total of 64K bytes of address
space at a time, regardless of how the data in that address space is used.
On the 45 and 70 class processors have the funky I/D bit, which gives 2
separate 16-bit address spaces, instruction or data, so the MMU and OS can
provide 2 64K bytes chunks of memory (for a total of 128K bytes) to the CPU,
however, the '17th' which picks which of those two 64K byte hunks is being
used is inferred from either and instruction or data fetch.




> and got somewhat confused, and wanted
> to verify my memory, that (absent Split I&D) user programs had virtual
> addresses in the range 0-0xffff, and kernels the same: 0-0xffff.
>
> Thanks, I know this has been discussed before, but I'm giving a talk
> at IWP9 next week and want to make sure I'm not missing something. The
> KT-11 doc left me uncertain.
>
> You gotta love those old DEC docs, complete with SSI logic diagrams ...
>

From tuhs at tuhs.org  Mon May  4 06:39:26 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Sun, 3 May 2026 16:39:26 -0400
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <CAC20D2OCnfohCbpA=xOG18UmJcAeAXknSfmeYV_bsOEphp0gig@mail.gmail.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <CAC20D2OCnfohCbpA=xOG18UmJcAeAXknSfmeYV_bsOEphp0gig@mail.gmail.com>
Message-ID: <CAC20D2MjE4FBc-M96C4Pg=Hrfg-SzA8fnhjqrsvjsiKm1N9Apw@mail.gmail.com>

As a PS and for completion, consider the registers:

Register Usage Conventions

   - R0 and R1 (Accumulators/Return Values): These are used as temporary
   scratchpads for expression evaluation. When a function returns a value, it
   is placed in R0; if the return value is a 32-bit long, the high-order bits
   are placed in R0 and the low-order bits in R1.
   - R2, R3, and R4 (Local Variables): These are used for local variables
   within a function. By convention, their values must be saved to the stack
   upon entering a procedure and restored before exiting, ensuring the calling
   function's data remains intact.
   - R5 (Frame Pointer / Environment Pointer): Known in UNIX as the FP, R5
   points to the current procedure's "activation record" or stack frame. It is
   used to access function arguments and local variables stored on the stack.
   - R6 (Stack Pointer / SP): This register tracks the top of the system
   stack. The hardware uses R6 implicitly during interrupts, traps, and
   subroutine calls (the JSR and RTS instructions).
   - R7 (Program Counter / PC): This register contains the memory address
   of the next instruction to be executed. Because it is a general register,
   it can be used with various addressing modes to provide immediate data and
   relative addressing



On Sun, May 3, 2026 at 4:35 PM Clem Cole <clemc at ccc.com> wrote:

> below
>
> On Sun, May 3, 2026 at 4:00 PM ron minnich via TUHS <tuhs at tuhs.org> wrote:
>
>> I was re-reading the KT-11 docs,
>
> A PDP-11 has 16-bit registers, so all addressing must be within a 64K
> boundary.
>
> There are a few versions of the MMU
>
>    - KS11 [CSS option for 11/20 -
>    http://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option]
>    - KT-11B [CSS option https://gunkies.org/wiki/KT11-B_Technical_Manual
>    ]
>    - KT-11C,CD  for the 11/45 class [45, 50, 55) [
>    https://bitsavers.trailing-edge.com/pdf/dec/pdp11/1145/EK-KT11C-MM-005-KT11-C_CD_Memory_Management_Maintenance_Manual_1976.pdf
>    ]\
>    - For the 11/70, the MMU is builtin and the PARs are SW compatible
>    with KT-11-C
>    - and the KT-11D for the 40 class [40, 35]
>    https://gunkies.org/wiki/KT11-D_Memory_Management_Unit
>    - later 40 class processors (34, 34A and 60) use the KT-11A which is
>    software compatible with the KT-11D
>
> In all cases, regardless of operation mode (user, supervisor, kernel), the
> CPU has a 16-bit address (virtual) space of 32K words (64K bytes).  The MMU
> then maps those 16 bits into either an 18 or 22-bit physical address
> space.  On a 40-class processor, that means a total of 64K bytes of address
> space at a time, regardless of how the data in that address space is used.
> On the 45 and 70 class processors have the funky I/D bit, which gives 2
> separate 16-bit address spaces, instruction or data, so the MMU and OS can
> provide 2 64K bytes chunks of memory (for a total of 128K bytes) to the CPU,
> however, the '17th' which picks which of those two 64K byte hunks is
> being used is inferred from either and instruction or data fetch.
>
>
>
>
>> and got somewhat confused, and wanted
>> to verify my memory, that (absent Split I&D) user programs had virtual
>> addresses in the range 0-0xffff, and kernels the same: 0-0xffff.
>>
>> Thanks, I know this has been discussed before, but I'm giving a talk
>> at IWP9 next week and want to make sure I'm not missing something. The
>> KT-11 doc left me uncertain.
>>
>> You gotta love those old DEC docs, complete with SSI logic diagrams ...
>>
>

From tuhs at tuhs.org  Mon May  4 07:10:47 2026
From: tuhs at tuhs.org (Phil Budne via TUHS)
Date: Sun, 03 May 2026 17:10:47 -0400
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <20260503203324.B64EC107B7BB2@ary.qy>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
Message-ID: <202605032110.643LAlMZ013157@ultimate.com>

John Levine wrote:
> ... there was an eight-entry map that
> mapped 8K pages of program addresses to 8K pages of physical memory.

DEC docs (or at least the KT11-C document Clem posted a link for) call
them "variable size pages"; each of them can map anything from 32
words up to 4KW (8KB), but I think it's fairer to think of each (mode
x I/D) virtual address space as broken into eight segments at 8KW
boundaries.  Each segment has the option to grow from up from the
bottom of the segment, or down from the top.

Not all systems make it easy to restart an instruction after a "fault"
like one might expect from hearing the word "paging"

CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared
memory segments.

From tuhs at tuhs.org  Mon May  4 16:19:59 2026
From: tuhs at tuhs.org (Phil Budne via TUHS)
Date: Mon, 04 May 2026 02:19:59 -0400
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <202605032110.643LAlMZ013157@ultimate.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
Message-ID: <202605040619.6446JxTO022824@ultimate.com>

I wrote:
> CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared
> memory segments.

The sysv_pdp11.tgz I just found has has a library shmsys.c which
indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c
AND I've yet to spot the kernel support in the available CB Unix
listings...

From tuhs at tuhs.org  Mon May  4 17:18:20 2026
From: tuhs at tuhs.org (Jonathan Gray via TUHS)
Date: Mon, 4 May 2026 17:18:20 +1000
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <202605040619.6446JxTO022824@ultimate.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
 <202605040619.6446JxTO022824@ultimate.com>
Message-ID: <afhIPLvbxG5uORz0@largo.jsg.id.au>

On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote:
> I wrote:
> > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared
> > memory segments.
> 
> The sysv_pdp11.tgz I just found has has a library shmsys.c which
> indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c
> AND I've yet to spot the kernel support in the available CB Unix
> listings...

You may be looking for MAUS?

https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf

maus.c cbunix4.pdf pp 64-66
sysent.c cbunix6.pdf pp 50-52

	1, &maus,			/* 58 = set up MAUS segment reg */

From tuhs at tuhs.org  Mon May  4 17:50:53 2026
From: tuhs at tuhs.org (Arnold Robbins via TUHS)
Date: Mon, 04 May 2026 01:50:53 -0600
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <afhIPLvbxG5uORz0@largo.jsg.id.au>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
 <202605040619.6446JxTO022824@ultimate.com>
 <afhIPLvbxG5uORz0@largo.jsg.id.au>
Message-ID: <202605040750.6447orQ8041827@freefriends.org>

Jonathan Gray via TUHS <tuhs at tuhs.org> wrote:

> On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote:
> > I wrote:
> > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared
> > > memory segments.
> > 
> > The sysv_pdp11.tgz I just found has has a library shmsys.c which
> > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c
> > AND I've yet to spot the kernel support in the available CB Unix
> > listings...
>
> You may be looking for MAUS?
>
> https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf
>
> maus.c cbunix4.pdf pp 64-66
> sysent.c cbunix6.pdf pp 50-52
>
> 	1, &maus,			/* 58 = set up MAUS segment reg */

The UNIX 4.0 release notes that Matt sent out a little while ago
mentions that on the PDP-11 MAUS is supported instead of the
shared memory sys calls.  FWIW.

Arnold

From tuhs at tuhs.org  Mon May  4 19:35:38 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Mon, 04 May 2026 09:35:38 +0000
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <202605040750.6447orQ8041827@freefriends.org>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
 <202605040619.6446JxTO022824@ultimate.com> <afhIPLvbxG5uORz0@largo.jsg.id.au>
 <202605040750.6447orQ8041827@freefriends.org>
Message-ID: <UxUBMQWOLWZdXNKX9tpEfI4FOcMvr8tcEO2vfX9gf_PfaLAIxNxGAYfoguSGCAVkxIgLKr93cFGVXO2Y7f20Q7aOKNabl4BuSTrH2Zozy1Q=@protonmail.com>

On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS <tuhs at tuhs.org> wrote:

> Jonathan Gray via TUHS <tuhs at tuhs.org> wrote:
> 
> > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote:
> > > I wrote:
> > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared
> > > > memory segments.
> > >
> > > The sysv_pdp11.tgz I just found has has a library shmsys.c which
> > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c
> > > AND I've yet to spot the kernel support in the available CB Unix
> > > listings...
> >
> > You may be looking for MAUS?
> >
> > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf
> >
> > maus.c cbunix4.pdf pp 64-66
> > sysent.c cbunix6.pdf pp 50-52
> >
> > 	1, &maus,			/* 58 = set up MAUS segment reg */
> 
> The UNIX 4.0 release notes that Matt sent out a little while ago
> mentions that on the PDP-11 MAUS is supported instead of the
> shared memory sys calls.  FWIW.
> 
> Arnold
>

MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11 specific.  Since shm is expected in future non-PDP-11 UNIX, a separate, more portable solution was developed (I don't know the internal name) which supports all the future platforms, but isn't workable in PDP-11 UNIX.   Between this and other factors, SVR2 is the last USG UNIX to touch the PDP-11 as far as prevailing literature is concerned.  For instance, I have the SVR2 System Release Description and it still mentions PDP-11/70 compatibility.  That said, machid(1) as of SVR4 manuals lists pdp11 as a reportable target.  I've never confirmed whether this is simply a matter of aged documentation or if somewhere deep inside AT&T they kept SysV going on PDP-11 past SVR2.  For the record, 3B20 and 3B21 UNIX was supported long after SysV went the SCO route in the from of UNIX/RTR.  That's only to point out that some of the 70s UNIX platforms do have continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere in BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70.  Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though.  I have a Lucent training document on C in shipment currently, I'll see soon if it lends any credence to late-era PDP-11 support in the USG or BTL streams.  Given BTL moving to VAX-11 in the early 80s though, anything post-that e.g. Lucent it's may yield nothing useful in the PDP-11 longevity question.

- Matt G.

From tuhs at tuhs.org  Mon May  4 20:07:24 2026
From: tuhs at tuhs.org (Arnold Robbins via TUHS)
Date: Mon, 04 May 2026 04:07:24 -0600
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <UxUBMQWOLWZdXNKX9tpEfI4FOcMvr8tcEO2vfX9gf_PfaLAIxNxGAYfoguSGCAVkxIgLKr93cFGVXO2Y7f20Q7aOKNabl4BuSTrH2Zozy1Q=@protonmail.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
 <202605040619.6446JxTO022824@ultimate.com>
 <afhIPLvbxG5uORz0@largo.jsg.id.au>
 <202605040750.6447orQ8041827@freefriends.org>
 <UxUBMQWOLWZdXNKX9tpEfI4FOcMvr8tcEO2vfX9gf_PfaLAIxNxGAYfoguSGCAVkxIgLKr93cFGVXO2Y7f20Q7aOKNabl4BuSTrH2Zozy1Q=@protonmail.com>
Message-ID: <202605041007.644A7ObI052144@freefriends.org>

segaloco via TUHS <tuhs at tuhs.org> wrote:

> On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS <tuhs at tuhs.org> wrote:
>
> > Jonathan Gray via TUHS <tuhs at tuhs.org> wrote:
> > 
> > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote:
> > > > I wrote:
> > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared
> > > > > memory segments.
> > > >
> > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which
> > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c
> > > > AND I've yet to spot the kernel support in the available CB Unix
> > > > listings...
> > >
> > > You may be looking for MAUS?
> > >
> > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf
> > >
> > > maus.c cbunix4.pdf pp 64-66
> > > sysent.c cbunix6.pdf pp 50-52
> > >
> > > 	1, &maus,			/* 58 = set up MAUS segment reg */
> > 
> > The UNIX 4.0 release notes that Matt sent out a little while ago
> > mentions that on the PDP-11 MAUS is supported instead of the
> > shared memory sys calls.  FWIW.
> > 
> > Arnold
> >
>
> MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11
> specific.  Since shm is expected in future non-PDP-11 UNIX, a separate,
> more portable solution was developed (I don't know the internal name)
> which supports all the future platforms, but isn't workable in PDP-11
> UNIX.   Between this and other factors, SVR2 is the last USG UNIX to touch
> the PDP-11 as far as prevailing literature is concerned.  For instance, I
> have the SVR2 System Release Description and it still mentions PDP-11/70
> compatibility.  That said, machid(1) as of SVR4 manuals lists pdp11
> as a reportable target.  I've never confirmed whether this is simply a
> matter of aged documentation or if somewhere deep inside AT&T they kept
> SysV going on PDP-11 past SVR2.  For the record, 3B20 and 3B21 UNIX was
> supported long after SysV went the SCO route in the from of UNIX/RTR.
> That's only to point out that some of the 70s UNIX platforms do have
> continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere
> in BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70.
> Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though.
> I have a Lucent training document on C in shipment currently, I'll see
> soon if it lends any credence to late-era PDP-11 support in the USG
> or BTL streams.  Given BTL moving to VAX-11 in the early 80s though,
> anything post-that e.g. Lucent it's may yield nothing useful in the
> PDP-11 longevity question.
>
> - Matt G.

It is super unlikely that anything past SVR2 ran on the PDP-11. Demand
paging was introduced sometime in the SVR3 period, along with STREAMS
networking, the filesystem switch and RFS, and SVR4 was architectually
very much like SunOS, with demand paging, a vnode-based filesystem
architecture, both traditional and BSD fast filesystems, and with socket
and STREAMS networking, NFS and I think even RFS.

WWWWAAAAYYY too much to shoe-horn into an -11.

The porting platform changed over time also, from -11 to Vax to 386 and 3Bxx,
with older ones being dropped along the way.

Arnold

From tuhs at tuhs.org  Tue May  5 01:59:59 2026
From: tuhs at tuhs.org (ron minnich via TUHS)
Date: Mon, 4 May 2026 08:59:59 -0700
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <202605041007.644A7ObI052144@freefriends.org>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
 <202605040619.6446JxTO022824@ultimate.com> <afhIPLvbxG5uORz0@largo.jsg.id.au>
 <202605040750.6447orQ8041827@freefriends.org>
 <UxUBMQWOLWZdXNKX9tpEfI4FOcMvr8tcEO2vfX9gf_PfaLAIxNxGAYfoguSGCAVkxIgLKr93cFGVXO2Y7f20Q7aOKNabl4BuSTrH2Zozy1Q=@protonmail.com>
 <202605041007.644A7ObI052144@freefriends.org>
Message-ID: <CAP6exYJ2FoXxMAPvgdg0w9t3VFw3FD6bKODP5v19cofwbZ2q0A@mail.gmail.com>

related question, when people started getting their VAXes, what was the
smallest configuration that ran Unix?

On Mon, May 4, 2026 at 3:07 AM Arnold Robbins via TUHS <tuhs at tuhs.org>
wrote:

> segaloco via TUHS <tuhs at tuhs.org> wrote:
>
> > On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS <
> tuhs at tuhs.org> wrote:
> >
> > > Jonathan Gray via TUHS <tuhs at tuhs.org> wrote:
> > >
> > > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote:
> > > > > I wrote:
> > > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported
> shared
> > > > > > memory segments.
> > > > >
> > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which
> > > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in
> sysent.c
> > > > > AND I've yet to spot the kernel support in the available CB Unix
> > > > > listings...
> > > >
> > > > You may be looking for MAUS?
> > > >
> > > >
> https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf
> > > >
> > > > maus.c cbunix4.pdf pp 64-66
> > > > sysent.c cbunix6.pdf pp 50-52
> > > >
> > > >   1, &maus,                       /* 58 = set up MAUS segment reg */
> > >
> > > The UNIX 4.0 release notes that Matt sent out a little while ago
> > > mentions that on the PDP-11 MAUS is supported instead of the
> > > shared memory sys calls.  FWIW.
> > >
> > > Arnold
> > >
> >
> > MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11
> > specific.  Since shm is expected in future non-PDP-11 UNIX, a separate,
> > more portable solution was developed (I don't know the internal name)
> > which supports all the future platforms, but isn't workable in PDP-11
> > UNIX.   Between this and other factors, SVR2 is the last USG UNIX to
> touch
> > the PDP-11 as far as prevailing literature is concerned.  For instance, I
> > have the SVR2 System Release Description and it still mentions PDP-11/70
> > compatibility.  That said, machid(1) as of SVR4 manuals lists pdp11
> > as a reportable target.  I've never confirmed whether this is simply a
> > matter of aged documentation or if somewhere deep inside AT&T they kept
> > SysV going on PDP-11 past SVR2.  For the record, 3B20 and 3B21 UNIX was
> > supported long after SysV went the SCO route in the from of UNIX/RTR.
> > That's only to point out that some of the 70s UNIX platforms do have
> > continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere
> > in BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70.
> > Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though.
> > I have a Lucent training document on C in shipment currently, I'll see
> > soon if it lends any credence to late-era PDP-11 support in the USG
> > or BTL streams.  Given BTL moving to VAX-11 in the early 80s though,
> > anything post-that e.g. Lucent it's may yield nothing useful in the
> > PDP-11 longevity question.
> >
> > - Matt G.
>
> It is super unlikely that anything past SVR2 ran on the PDP-11. Demand
> paging was introduced sometime in the SVR3 period, along with STREAMS
> networking, the filesystem switch and RFS, and SVR4 was architectually
> very much like SunOS, with demand paging, a vnode-based filesystem
> architecture, both traditional and BSD fast filesystems, and with socket
> and STREAMS networking, NFS and I think even RFS.
>
> WWWWAAAAYYY too much to shoe-horn into an -11.
>
> The porting platform changed over time also, from -11 to Vax to 386 and
> 3Bxx,
> with older ones being dropped along the way.
>
> Arnold
>

From tuhs at tuhs.org  Tue May  5 02:26:03 2026
From: tuhs at tuhs.org (Paul Winalski via TUHS)
Date: Mon, 4 May 2026 12:26:03 -0400
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <CAP6exYJ2FoXxMAPvgdg0w9t3VFw3FD6bKODP5v19cofwbZ2q0A@mail.gmail.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
 <202605040619.6446JxTO022824@ultimate.com> <afhIPLvbxG5uORz0@largo.jsg.id.au>
 <202605040750.6447orQ8041827@freefriends.org>
 <UxUBMQWOLWZdXNKX9tpEfI4FOcMvr8tcEO2vfX9gf_PfaLAIxNxGAYfoguSGCAVkxIgLKr93cFGVXO2Y7f20Q7aOKNabl4BuSTrH2Zozy1Q=@protonmail.com>
 <202605041007.644A7ObI052144@freefriends.org>
 <CAP6exYJ2FoXxMAPvgdg0w9t3VFw3FD6bKODP5v19cofwbZ2q0A@mail.gmail.com>
Message-ID: <CABH=_VQSqiqykefwsTufjGpkYLAWxaqd-YuF0J1tCxFioqioHQ@mail.gmail.com>

On Mon, May 4, 2026 at 12:07 PM ron minnich via TUHS <tuhs at tuhs.org> wrote:

> related question, when people started getting their VAXes, what was the
> smallest configuration that ran Unix?
>

Originally the smallest memory configuration for the VAX-11/780 was 128KB.
My alma mater was a hardware beta test site for the VAX-11/780 (in 1977).
Our machine had 1MB of memory.  I joined DEC as a software engineer in
1980.  Nobody in the VAX software group knew of anyone running a 128KB VAX
of any model.  When VAX/VMS Version 4.0 came out in the mid-1980s there
were still a few (4 or 5) 512KB VAX systems out there running VAX/VMS.  VMS
V4 would not run properly with less than 1MB of memory.  After quite a bit
of bellyaching and wrangling DEC decided that it was cheaper to simply give
those 4 or 5 customers 512K more of memory for free rather than try to
shoehorn VMS V4 into 512KB.

For all later VAXen the minimum memory size was measured in megabytes.

I would imagine that Unix would have no problem running on a 128KB VAX
system, if any of those actually existed.  More likely the smallest Unix
configuration would be a 512KB VAX-11/725 or 11/730.

-Paul W.

From tuhs at tuhs.org  Tue May  5 02:36:02 2026
From: tuhs at tuhs.org (Jon Forrest via TUHS)
Date: Mon, 4 May 2026 09:36:02 -0700
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <CAP6exYJ2FoXxMAPvgdg0w9t3VFw3FD6bKODP5v19cofwbZ2q0A@mail.gmail.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
 <202605040619.6446JxTO022824@ultimate.com> <afhIPLvbxG5uORz0@largo.jsg.id.au>
 <202605040750.6447orQ8041827@freefriends.org>
 <UxUBMQWOLWZdXNKX9tpEfI4FOcMvr8tcEO2vfX9gf_PfaLAIxNxGAYfoguSGCAVkxIgLKr93cFGVXO2Y7f20Q7aOKNabl4BuSTrH2Zozy1Q=@protonmail.com>
 <202605041007.644A7ObI052144@freefriends.org>
 <CAP6exYJ2FoXxMAPvgdg0w9t3VFw3FD6bKODP5v19cofwbZ2q0A@mail.gmail.com>
Message-ID: <7a330657-8294-4965-9878-9c549644cb30@gmail.com>



On 5/4/26 8:59 AM, ron minnich via TUHS wrote:
> related question, when people started getting their VAXes, what was the
> smallest configuration that ran Unix?

This isn't an exact answer to your question but in 1978(?) I
did some contracting for a place in Santa Barbara that had
just accepted delivery of a VAX 11/780 with 256K (!!!) of
RAM. It ran VMS, not Unix, and was barely a single user
system.

They soon added another 512K and it made a miraculous
improvement.

Jon


From tuhs at tuhs.org  Tue May  5 03:04:36 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Mon, 4 May 2026 13:04:36 -0400
Subject: [TUHS] quick question on PDP-11 addressing
In-Reply-To: <UxUBMQWOLWZdXNKX9tpEfI4FOcMvr8tcEO2vfX9gf_PfaLAIxNxGAYfoguSGCAVkxIgLKr93cFGVXO2Y7f20Q7aOKNabl4BuSTrH2Zozy1Q=@protonmail.com>
References: <CAP6exYKm1uAz6FCXVh+SZC+6mk4HSjA=pSJ-58J_iUiPxoR0tw@mail.gmail.com>
 <20260503203324.B64EC107B7BB2@ary.qy>
 <202605032110.643LAlMZ013157@ultimate.com>
 <202605040619.6446JxTO022824@ultimate.com> <afhIPLvbxG5uORz0@largo.jsg.id.au>
 <202605040750.6447orQ8041827@freefriends.org>
 <UxUBMQWOLWZdXNKX9tpEfI4FOcMvr8tcEO2vfX9gf_PfaLAIxNxGAYfoguSGCAVkxIgLKr93cFGVXO2Y7f20Q7aOKNabl4BuSTrH2Zozy1Q=@protonmail.com>
Message-ID: <CAC20D2OqLmtPXE3zDy5fAG2N_T59JZuiu8s01GF9q-JAfe6dFg@mail.gmail.com>

below.

On Mon, May 4, 2026 at 5:35 AM segaloco via TUHS <tuhs at tuhs.org> wrote:

> On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS <tuhs at tuhs.org
> <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=tuhs at tuhs.org>> wrote:
>
> > Jonathan Gray via TUHS <tuhs at tuhs.org
> <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=tuhs at tuhs.org>> wrote:
> >
> > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote:
> > > > I wrote:
> > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared
> > > > > memory segments.
> > > >
> > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which
> > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c
> > > > AND I've yet to spot the kernel support in the available CB Unix
> > > > listings...
> > >
> > > You may be looking for MAUS?
> > >
> > >
> https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf
> > >
>
For folk playing at home, Jonathan is pointing to the10 PDF's that are
scans (but not OCRed) pr(1) listings of CB Unix 2.3  source code

https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/raw/SourceCode/

> > > maus.c cbunix4.pdf pp 64-66
> > > sysent.c cbunix6.pdf pp 50-52
> > >
> > >     1, &maus,                       /* 58 = set up MAUS segment reg */
> >
>
>
> MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11
> specific.

Right, to quote from page III "Acknowledgments" section on page III of
CB-UNIX *Programmer's Manual Edition 2.3 *  [
https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/raw/cbunix_intro.pdf
]

"The form of this manual follows that of the *UNIX Programmer's
Manual-Seventh Edition, Volume 1 *developed by M. D . Mcllroy. A large part
of the present manual's contents is descended from the *UNIX Programmer's
Manual-Sixth Edition* by K. Thompson and D. M. Ritchie (Bell Telephone
Laboratories, May 1975) and the *PWB/UNIX User's Manuals* by I. A. Dolotta,
R.C. Haight, and E. M. Piskorik, eds. (Bell Telephone Laboratories, May
1977). A special credit should also be given to the UNIX support effort of
department 3624; their support of UNIX helped make this manual possible.
The number of our colleagues who have contributed to UNIX and CB-UNIX
software and documentation is, by now, too large to list here, but the
usefulness and acceptance of UNIX and of CB-UNIX are true measures of their
collective success."



Now check the readme.txt file at the top of the CB_Unix TUHS archives area.
The reader learns that CB-UNIX

"was developed to address deficiencies inherent in Research Unix, notably
the lack of interprocess communication and file locking, considered
essential for a database management system. Several Bell System *operation
support system products* were based on CB/UNIX, such as the *Switching
Control Center System*. The primary innovations were power-fail restart,
line disciplines, terminal types, and IPC features similar to System V's
messages and shared memory."

Remember, this readme.txt file was written many years later. UNIX
3.0/System III was still in development, so the mention of System V is
intended to offer the reader a modern context to a historical fact.

Thus, the first editions of CB-UNIX began as a set of changes to the first
Research Editions that ran on the 11/20 without an MMU that Ken had [the
DEC CSS group's KS-11]. Because it was running on an MMU-less PDP-11/20, I
will most likely date this as the Research First or Second editions.
CB-UNIX was developed for a product delivered to the Bell Operating
Companies called SCCS (Switching Control Center System) — which should not
be confused with Marc Rochkind's "Source Code Control System."

Dale DeJager was the supervisor of the team in Columbus, and he explains
what happened in a 1984 news message to net.unix [
https://groups.google.com/g/net.unix/c/-H9x36DMOBQ/m/P_G_s9SJBrgJ ] — note
the highlighting is mine:

... I was the supervisor of the group in Columbus for a number of years
that was responsible for the development of CB-UNIX. The system was
derived from
the UNIX operating system that was used in the SCCS (Switching Control
Center System), which incidentally was the first application of UNIX
outside of research. (UNIX was running on an 11/20, at the time, without
memory management and we deployed the first version of SCCS in New Jersey
Bell in New Brunswick, NJ.)

The SCCS version of UNIX had a number of unique features for the
times: semaphores
and line disciplines (in 1974!) for example. Hal Pearson was responsible
for semaphores, and Bill Snider for line disciplines.

Messages and shared memory were first added to CB-UNIX in about 1975 or 1976.
Shared memory was called MAUS (pronounced moss, standing for Multiple
Access User Space) and was derived from an earlier version done by R. J.
Purdue. CB-UNIX became rather widely accepted within BTL as a base for
turnkey Operations Systems--many of which have been described in the BSTJ.
Note that CB-UNIX was not a derivative of UNIX/RT, but of Version 6 and
Version 7. PWB UNIX† was also a derivative of Version 7. USG UNIX was
originally a derivative of Version 6 and 7 with some CB-UNIX facilities
added. Eventually, a decision was made to consolidate to two versions of
UNIX: UNIX/TS and UNIX/RT. RT was a derivative of MERT, and TS a derivative
of PWB UNIX. RT was to be used by Operations Systems, but was never too
widely accepted. Eventually, UNIX/TS was augmented to have many of the
features present in CB-UNIX (this was done by Roger Faulkner at Indian
Hill, BTL. This, in turn, became the base for UNIX 4.0, which was never
released externally. While this augmentation was going on, UNIX/TS was
being changed into UNIX 3.0 which was release externally as SYSTEM III.

In more recent history, CB-UNIX has been eliminated entirely in favor of UNIX
5.0. (one reason is because it never ran on anything other than the 11/70)

I once had a viewgraph with all this on it which I had great fun trying to
explain.


As Dale says here, the target system for CB-UNIX was an 11/70. My
understanding is that it wouldn't boot on a 40-class processor, but it
would run on a 45-class. By the time of the CB-UNIX release (2.3), Research
Seventh, as well as UNIX/TS from USG in Summit, had been released.


> Since shm is expected in future non-PDP-11 UNIX

Let me put that in context.  The Summit-based Unix Support Group was a
fairly recent creation [76-77 timeframe, I believe].  But the team, like
Dale's in Columbus and other Bell Labs sites, wrote programs in support of
the Bell Operating Companies.  Those teams had been relying on features
that CB-UNIX supported.

By the mid-late 70's, AT&T management realized that UNIX >>system<<
development was going on at many (they would determine, too many) BTL
sites.  This was the basis for USG in Summit (BTW — my experience at the
time is that it may have cut down a number of "kernel" hacks and hackers,
it was still very widespread for a reason I'll not mention here).   Dale
describes this as: "Eventually, a decision was made to consolidate to
two versions
of UNIX: UNIX/TS and UNIX/RT."

But to do that, features that were private to some internal teams, like
those from CB-UNIX, needed to be included in the standard versions, so that
"products" being developed in the different labs and *AT&T subcompanies
could run on the "common" system.*

So the "expectation" really was a "customer requirement" from the other
labs and the operating companies.  USG's target customer within the Bell
System had production code that needed to run.  If AT&T were to have a
"standard OS" for the Bell System, shared memory and several other CB-UNIX
features would have to be supported.




> , a separate, more portable solution was developed (I don't know the
> internal name) which supports all the future platforms, but isn't workable
> in PDP-11 UNIX.

I'm not so sure about the statement that the PDP-11 is unworkable, as it
has been the workhorse for the entire Bell System.  According to some of my
DEC colleagues, AT&T was not only the #1 customer for DEC but, for a long
time, continued to buy 11/70s instead of Vaxen.  As I understand it, AT&T's
taste for the 11/70 is one of the reasons DEC began developing the
single-chip F-11, T-11, and finally the J-11; along with the J-11-based
systems, the 11/73, 11/83, and 11/93 in 1984, 1985, and 1990.   However,
full production of AT&T's own BELLMAC-32, *a.k.a.*, 32100, started in 1982,
and by 1984, we see their 3B2, 3B5, and 3B15 systems that are built on
them.

I think support for newer versions of the operating system was just not
prioritized. That is to say, the need for spending effort on it by then was
not there. as much as by that time the 11/70 was being phased out as both a
development and operating company deployed system.



>  Between this and other factors, SVR2 is the last USG UNIX to touch the
> PDP-11 as far as prevailing literature is concerned.  For instance, I have
> the SVR2 System Release Description and it still mentions PDP-11/70
> compatibility.

SVR1 supported both Vax and PDP-11.  My memory was that the commercial
customers outside the Bell Systems could order either version.   A bit
later, SVR2 still supported the PDP-11 architecture, but it was its
transitional release (what DEC would have called 'legacy products').
The VAX-11/780
replaced the PDP-11 as the official "reference platform" (*a.k.a.,* porting
base) for this version, meaning all subsequent development and
optimizations were first implemented on the VAX before being ported to
other machines. By SVR3, the 3B2 was.



> That said, machid(1) as of SVR4 manuals lists pdp11 as a reportable
> target.  I've never confirmed whether this is simply a matter of aged
> documentation or if somewhere deep inside AT&T they kept SysV going on
> PDP-11 past SVR2.

It was a big enough company, particularly when you include the operating
companies.  So even after being split up, the PDP-11 was still a large
installed base within the former Bell System.  But the ROI on continued
support was clearly not there for USG's management.



> For the record, 3B20 and 3B21 UNIX was supported long after SysV went the
> SCO route in the from of UNIX/RTR.

That's only to point out that some of the 70s UNIX platforms do have
> continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere in
> BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70.

I agree, see previous comment.


> Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though.

Agreed.



> I have a Lucent training document on C in shipment currently, I'll see
> soon if it lends any credence to late-era PDP-11 support in the USG or BTL
> streams.  Given BTL moving to VAX-11 in the early 80s though, anything
> post-that e.g. Lucent it's may yield nothing useful in the PDP-11 longevity
> question.

I understand.

Clem

† Dale is referring to PWB 2.0 in this context.  The original PWB (a.k.a.
1.0) was a delta to Research Sixth.

From tuhs at tuhs.org  Wed May  6 15:26:01 2026
From: tuhs at tuhs.org (Thalia Archibald via TUHS)
Date: Wed, 06 May 2026 05:26:01 +0000
Subject: [TUHS] DECtapes under the UNIX room floor
Message-ID: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>

In Pirzada’s 1988 thesis, he mentions some DECtapes that were found under the
UNIX room floor while he was searching for early distributions. Are these the
Dennis_Tapes?

> However, some old paper tapes and DECtapes of unknown content were discovered
> underneath the floor-boards in the UNIX room. [page 64]
    https://www.tuhs.org/Archive/Documentation/Theses/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf

> All, way back when, Dennis sent me [Warren] some DECtape images to look after.
    https://www.tuhs.org/pipermail/tuhs/2023-July/028590.html

Thalia

From tuhs at tuhs.org  Wed May  6 15:47:27 2026
From: tuhs at tuhs.org (Warren Toomey via TUHS)
Date: Wed, 6 May 2026 15:47:27 +1000
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
Message-ID: <afrV7zih3d/jWs9y@minnie.tuhs.org>

On Wed, May 06, 2026 at 05:26:01AM +0000, Thalia Archibald via TUHS wrote:
> In Pirzada’s 1988 thesis, he mentions some DECtapes that were found under the
> UNIX room floor while he was searching for early distributions. Are these the
> Dennis_Tapes?

I would almost certainly say yes. I can dig out Dennis' original e-mail
when he first mentions the DEC tapes. Will try to find it ...

	Warren

From tuhs at tuhs.org  Wed May  6 15:57:51 2026
From: tuhs at tuhs.org (Warren Toomey via TUHS)
Date: Wed, 6 May 2026 15:57:51 +1000
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
Message-ID: <afrYX6jMY/QHv4Xg@minnie.tuhs.org>

On Wed, May 06, 2026 at 05:26:01AM +0000, Thalia Archibald via TUHS wrote:
> In Pirzada’s 1988 thesis, he mentions some DECtapes that were found under the
> UNIX room floor while he was searching for early distributions. Are these the
> Dennis_Tapes?

Here's what I've got. In Jan 1999 I sent this e-mail to dmr:

    Now, about that V2 DECtape. In the July 1984 issue of ;login: there is a
    Unix trivia quiz.  At the top, it says:
    
            The following quiz was distributed at the Salt Lake City conference
    by Rob Pike... Jim McKie had the best score for an individual (57) and was
    awarded an authenticated 1972 DECtape containing UNIX Version 2.
    
    In 1995, I emailed Jim and asked him what had happened to the tape? He
    replied:
    
            a couple of years ago we sent that dectape along with a bunch of
            others we found under to floor to keith bostic at berkeley who
            had resurrected a dectape drive. i don't remember getting it back.
            i'll enquire.
    
            i loved pdp11's.                  
    
    So I assume that it must have been one of the DECtapes you had Keith read.
    However, somehow it got lost because you haven't mentioned it.              
    
    So: do you guys still have those DECtapes, or does Keith have them?

But earlier, in Sept 1997, Dennis has sent me this e-mail:

    The files here were read from old DECtapes made in the early 1970s.
    Paul Vixie and Keith Bostic unearthed a DECtape drive and
    made it work, we unearthed the tapes.
    
    The tapes were written in either the 'tap' or 'tp' format,
    which are similar in that they have a directory of up to 192
    entries at the start with names and other information including
    the size and tape address of the files.  'tp' was the later
    format, and was in use by November 1973, the date of the 4th edition manual.
    With `tap', the times associated with the files were recorded
    in pre-modern units: sixtieths of a second, from an origin that
    changed.  The first three editions of the manual had BUGS sections
    noting that 32 bits can represent only about 2.5 years in this
    unit, and this implied continuing crises as the time overflowed.
    
    I believe that the change to use seconds for Unix time took place
    along with the change to the C version of the operating system, which
    occurred about the end of the summer of 1973, and also that the change
    from `tap' to `tp' took place at the same time.  (This is consistent
    with the dates of the 3rd and 4th edition manuals).
    
    Thus the dates recorded with the `tp' tapes probably correspond
    reliably to the modification dates of the files at the time
    of saving them (of course, this gives only a upper bound on
    their creation, since they might have been copied or trivially
    touched just before saving them).
    
    Recovering the proper dates for the `tap' tapes is less reliable,
    because there was at least one change of epoch (from 1971 to 1972)
    during the period they could possibly have been produced.
    I believe that the 1972 epoch is most likely the correct one
    for the tapes here.
    
    apl
            Ken's apl program, together with his rendition of
            astro (translated from Morris's Fortran).
            Probably OK dates, 1975-76.
    
    config
            Ken's program for configuring PDP11s.  It told you
            price, maintenance, checked for bus loading.
            Interesting for DEC price lists in 1974.
    
    dmr
            Random stuff from my directory.  Most probable dates: 1972.
            The `paper' directory contains a version
            of the original SOSP Unix paper (haven't compared
            it with the CACM version).
            cgd appears to be an experiment in converting
            Fortran threaded code to machine language,
            using a warmed over version of the earliest C
            code generator.  It's written in NB, not C.
            fd is some fortran programs, in particular a
            polynomial root-finder I found somewhere.
    
            aman is some version of the PDP-11 assembler manual.
            fd is a fortran program for plotting functions
            of 2 variables.
    
            notes1 and notes2 are evidently notes I made for myself
            for a talk on unix.  They are quite interesting.
    
            tty.s is evidently the terminal processing routine for an
            assembly-language version of unix.  note that it handles
            IBM 2741 terminals with two kinds of typeballs
            (938 and correspondence).
    
            crypt.c encrypts using a variant of the Hagelin machine.
    
            pig.b is an interesting artifact:  it is a B program
            that echoes what you type in Pig latin.  (Incidentally,
            there is a translation of this program into C, dated 1978,
            in a subdirectory that still spins on a disk attached to
            the Unix machine where I get my mail.)
    
    dmr2
            the let directory contains drafts of a bunch of letters
            to people who asked about unix in early days.  (lett6
            is to andy tanenbaum).
    
            The let directory contains drafts of a bunch of letters
            to people who asked about unix in early days.  (lett6
            is to andy tanenbaum).
    
            Other bits: restric discusses some early thoughts
            about types in C.  I don't know who it was addressed
            to (perhaps even to myself).  ct is an even briefer
            list about what I though was important.
    
            iosys is a manual for writing system device drivers.
    
    e-pi
            Our programs to compute e and pi to a million places.
            The one for e worked; it took some months on a time-shared
            PDP-11 without memory mapping.
            Incidentally the <SO>J<SI> directory name is correct:
            this sequence printed the greek letter pi on a Teletype
            model 37.  Plan 9 won't let me create this.  It wants
            me to use Unicode!
    
    games
            Ken's work on various games.  Check out chomp/c0.c,
            which has a briefly-existing form of structure
            declaration using parentheses instead of braces.
    
    ken
            check out the values of the AT&T Savings plan in the
            early 70s (plan), and what interested Ken's son (corey/*)
            then.
    
    ken-du
            Here, you can read our wtmp files from 1974 and 1975.
    
    ken-sky
            A bunch of interesting old ken stuff (eg a version of
            the units program from the days when the dollar fetched
            302.7 yen)
    
    last1120c
            The source for a version of C that compiled for the
            PDP-11/20.  It didn't have structures, it didn't have
            #define, and pointers were declared p[].  But look!
            The initialization routine says
    
                    init("float", 2);
                    init("double", 3);
            /*      init("long", 4);  */
                    init("auto", 5);
                    init("extern", 6);
    
    nsys
            If the decoding of the date on the tape is correct (Aug 1973),
            this is the source for the earliest C version of Unix
            likely to be recovered.  `nsys' meant the C version
            rather than the assembly version, and Aug 73 is plausible for
            a running instance of this system.
    
    prestruct-c
            This is approximately the same era as `last1120c,'
            but 6 months later; despite the name, this compiler now
            handles structures.  (The struct keyword
            has displaced `long' as keyword number 4!)  The name of
            the tape indicates that the state of the compiler
            was saved just before converting it to use structures
            inside itself.
    
            The compiler is much less complete--just
            the c??.c files, not the tables for code generation.
    
    s1
            I haven't cracked this yet.
    
    s2
            Is not source, but a dump of (parts of) /bin, /etc,
            /usr/lib, and bits of a few other directories.
            Caution!  The tape uses absolute pathnames,
            and is dangerous to extract unless you want to install
            old PDP-11 binaries.  (tap format).
    
    sys-dsu
            This system didn't come directly from us.  After
            poking around it for a while I found a file containing
            this (in cr.h):
    
            /*****************************************************************
             **                                                             **
             **                U C L A  Data Secure Unix                    **
             **                                                             **
             **                     Copyright 1977                          **
             **                                                             **
             **    Mark Kampe, Charles Kline, Gerald Popek, Evelyn Walton   **
             **                                                             **
             *****************************************************************/
    
            So, it appears that `dsu' is `data-secure unix' and this is a
            record of one of the early security projects!  They must
            have sent it to us.  Might be fun to examine it; I suppose
            we should tell Gerry Popek of its existence.
    
    unix
            This is probably a `boot' tape; it has binary images of
            the system and some raw utility programs for use when booting
            (memory testers, loaders for diagnostics, and the like).

Cheers, Warren

From tuhs at tuhs.org  Wed May  6 16:47:59 2026
From: tuhs at tuhs.org (Warren Toomey via TUHS)
Date: Wed, 6 May 2026 16:47:59 +1000
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
Message-ID: <afrkHxRwi1rdjIqa@minnie.tuhs.org>

On Wed, May 06, 2026 at 05:26:01AM +0000, Thalia Archibald via TUHS wrote:
> In Pirzada’s 1988 thesis, he mentions some DECtapes that were found under the
> UNIX room floor while he was searching for early distributions. Are these the
> Dennis_Tapes?

And, finally, the tape images are at:
https://www.tuhs.org/Archive/Applications/Dennis_Tapes

Cheers, Warren

From tuhs at tuhs.org  Wed May  6 18:12:15 2026
From: tuhs at tuhs.org (Thalia Archibald via TUHS)
Date: Wed, 06 May 2026 08:12:15 +0000
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
Message-ID: <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>

Interesting. I’ve reviewed Dennis_Tapes before, but different bits stand out
this time.

On May 5, 2026, at 22:57, Warren Toomey wrote:
>            The following quiz was distributed at the Salt Lake City conference
>    by Rob Pike... Jim McKie had the best score for an individual (57) and was
>    awarded an authenticated 1972 DECtape containing UNIX Version 2.

Neat. I scanned a paper from this 1984 USENIX.
    https://archive.org/details/nielsen_object_kernel_1984

>    With `tap', the times associated with the files were recorded
>    in pre-modern units: sixtieths of a second, from an origin that
>    changed.

Was there a precedent for the choice of sixtieths of a second?

>    dmr
>            Random stuff from my directory.  Most probable dates: 1972.
>            The `paper' directory contains a version
>            of the original SOSP Unix paper (haven't compared
>            it with the CACM version).

This should be rendered and added to TUHS.

>            cgd appears to be an experiment in converting
>            Fortran threaded code to machine language,
>            using a warmed over version of the earliest C
>            code generator.  It's written in NB, not C.

This would be a great reference for reconstructing B/NB, along with the
well-known last1120c and prestruct-c!

>            notes1 and notes2 are evidently notes I made for myself
>            for a talk on unix.  They are quite interesting.

“UNIX is running on at least five PDP-11”. Modified 1972-03-15.
This should also be rendered.

>    dmr2
>            the let directory contains drafts of a bunch of letters
>            to people who asked about unix in early days.  (lett6
>            is to andy tanenbaum).

Dr. Paul C. Abegglen from the University of Utah requested UNIX on 1973-11-21
and Dennis replied in lett8. I wish I knew more about him, but I’ve found very
little. He’s from the Chemistry Department, not computer graphics like Martin
Newell (who apparently received UNIX V4 in June 1974), so a connection seems
tenuous. Martin recognized the name, but nothing else, when I asked.

>    games
>            Ken's work on various games.  Check out chomp/c0.c,
>            which has a briefly-existing form of structure
>            declaration using parentheses instead of braces.


This has the source to bj, moo, chess, wump, and ttt (but not cubic)!

>    ken
>            check out the values of the AT&T Savings plan in the
>            early 70s (plan), and what interested Ken's son (corey/*)
>            then.


distr/ has Ken’s 1975 licensee list that I’ve analyzed, but I glossed over
dsk{b,m,s}, which are the listings of the binary, manual, and source
distributions.

pwd/ is a password cracker.

>    ken-sky
>            A bunch of interesting old ken stuff (eg a version of
>            the units program from the days when the dollar fetched
>            302.7 yen)

nih.a is Ken’s trusting trust backdoor (https://research.swtch.com/nih).

>    sys-dsu
>            This system didn't come directly from us.  After
>            poking around it for a while I found a file containing
>            this (in cr.h):
> 
>            /*****************************************************************
>             **                                                             **
>             **                U C L A  Data Secure Unix                    **
>             **                                                             **
>             **                     Copyright 1977                          **
>             **                                                             **
>             **    Mark Kampe, Charles Kline, Gerald Popek, Evelyn Walton   **
>             **                                                             **
>             *****************************************************************/
> 
>            So, it appears that `dsu' is `data-secure unix' and this is a
>            record of one of the early security projects!  They must
>            have sent it to us.  Might be fun to examine it; I suppose
>            we should tell Gerry Popek of its existence.

It would be interesting to analyze this to tease out an intermediate snapshot
around January 1977.

>    unix
>            This is probably a `boot' tape; it has binary images of
>            the system and some raw utility programs for use when booting
>            (memory testers, loaders for diagnostics, and the like).

This is dated 1975-07-14. Has it been analyzed?

Thalia

From tuhs at tuhs.org  Wed May  6 18:32:14 2026
From: tuhs at tuhs.org (G. Branden Robinson via TUHS)
Date: Wed, 6 May 2026 03:32:14 -0500
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
Message-ID: <20260506083214.un4cgnw7xzkevbm3@illithid>

At 2026-05-06T08:12:15+0000, Thalia Archibald via TUHS wrote:
> >    With `tap', the times associated with the files were recorded
> >    in pre-modern units: sixtieths of a second, from an origin that
> >    changed.
> 
> Was there a precedent for the choice of sixtieths of a second?

We may be spoiled for choice; sexagesimal goes back over 4,000 years to
the ancient Sumerians.  ;-)

It's also the mains line frequency in North America.  I don't know if
anyone's ever clocked a digital computer that slow, but some peripherals
might have stuck a rectifier on the mains and used that for a clock.

Here's an app note from Renesas for a real-time clock that works that
way.  Crystals go home!

https://www.renesas.cn/zh/document/apn/an1342-using-60hz-power-line-frequency-accurate-real-time-clock-timebase

> >    dmr
> >            Random stuff from my directory.  Most probable dates: 1972.
> >            The `paper' directory contains a version
> >            of the original SOSP Unix paper (haven't compared
> >            it with the CACM version).
> 
> This should be rendered and added to TUHS.

...and gotten into Clem Cole's hands so we can see how groff fares as
the renderer.  ;-)

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20260506/e8312fd2/attachment.sig>

From tuhs at tuhs.org  Wed May  6 20:11:00 2026
From: tuhs at tuhs.org (John Cowan via TUHS)
Date: Wed, 6 May 2026 06:11:00 -0400
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <20260506083214.un4cgnw7xzkevbm3@illithid>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <20260506083214.un4cgnw7xzkevbm3@illithid>
Message-ID: <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>

On Wed, May 6, 2026 at 4:32 AM G. Branden Robinson via TUHS
<tuhs at tuhs.org> wrote:

\> > Was there a precedent for the choice of sixtieths of a second?
>
> We may be spoiled for choice; sexagesimal goes back over 4,000 years to
> the ancient Sumerians.  ;-)
>
> It's also the mains line frequency in North America.  I don't know if
> anyone's ever clocked a digital computer that slow, but some peripherals
> might have stuck a rectifier on the mains and used that for a clock.

See the '"Electronics" and "Computing" sections of
https://en.wikipedia.org/wiki/Jiffy_(time).

From tuhs at tuhs.org  Thu May  7 03:25:36 2026
From: tuhs at tuhs.org (Phil Budne via TUHS)
Date: Wed, 06 May 2026 13:25:36 -0400
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <20260506083214.un4cgnw7xzkevbm3@illithid>
 <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>
Message-ID: <202605061725.646HPaad081924@ultimate.com>

John Cowan wrote:
> See the '"Electronics" and "Computing" sections of
> https://en.wikipedia.org/wiki/Jiffy_(time).

The "Computing" section is pretty light on history.

DEC had a long history of 60Hz "line time" or "mains" clocks.

Wall clocks that use synchronous motors (demonstrated by Tesla in
1893, and common since the first part of the 20th century) depend on
long-term accuracy of line frequency.

PDP-7 UNIX depends on the PDP-4/7 feature of location 7 being
decremented at 60Hz and generating an interrupt on overflow.

The PDP-6 has a "power line frequency" clock in the built-in APR
(arithmetic processor) device, and the KA10 (PDP-10, the PDP-6
follow-on) has readable bit in the APR device indicating that the
system was on 50Hz power.

I know less about PDP-5/8 and PDP-11s, but line time clocks were
present, or available as options (DK8-EA on the PDP-8/E, DL11-W, KW11
on PDP-11s, the 11/03 has a switch on the power supply for LTC).

From tuhs at tuhs.org  Thu May  7 03:37:14 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Wed, 06 May 2026 17:37:14 +0000
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <202605061725.646HPaad081924@ultimate.com>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <20260506083214.un4cgnw7xzkevbm3@illithid>
 <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>
 <202605061725.646HPaad081924@ultimate.com>
Message-ID: <F6Zh5b_8SlGe1KNMLxJwCPXcawdW30tvWijmsrUiQ9Nb3q8_4xUlKFTsfg04Dga9ImYSYXDUVVv_CJ1fQrUoK0-mo_FkfhQ7h5DzMzWd9GI=@protonmail.com>

On Wednesday, May 6th, 2026 at 10:25, Phil Budne via TUHS <tuhs at tuhs.org> wrote:

> John Cowan wrote:
> > See the '"Electronics" and "Computing" sections of
> > https://en.wikipedia.org/wiki/Jiffy_(time).
> 
> The "Computing" section is pretty light on history.
> 
> DEC had a long history of 60Hz "line time" or "mains" clocks.

Well and tying in UNIX, BTL and AT&T had much experience in the realm of AC generation of all kinds between ringing generators, lamp interruptors, magnetos, and so on.  Heck, BTL was even working on a real-time clock circuit for PDP-11s in the mid 70s:

https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1048_A_Continuous_Service_RTC_for_Digital_Computers.pdf

- Matt G.

From tuhs at tuhs.org  Thu May  7 04:13:34 2026
From: tuhs at tuhs.org (Phil Budne via TUHS)
Date: Wed, 06 May 2026 14:13:34 -0400
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <F6Zh5b_8SlGe1KNMLxJwCPXcawdW30tvWijmsrUiQ9Nb3q8_4xUlKFTsfg04Dga9ImYSYXDUVVv_CJ1fQrUoK0-mo_FkfhQ7h5DzMzWd9GI=@protonmail.com>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <20260506083214.un4cgnw7xzkevbm3@illithid>
 <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>
 <202605061725.646HPaad081924@ultimate.com>
 <F6Zh5b_8SlGe1KNMLxJwCPXcawdW30tvWijmsrUiQ9Nb3q8_4xUlKFTsfg04Dga9ImYSYXDUVVv_CJ1fQrUoK0-mo_FkfhQ7h5DzMzWd9GI=@protonmail.com>
Message-ID: <202605061813.646IDYhk082929@ultimate.com>

> https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1048_A_Continuous_Service_RTC_for_Digital_Computers.pdf

Looks like a combination of

Looks like a combination "RTC" (real time, "time of year" (TOY), or
"wall" clock) like the PC BIOS/CMOS clock chip (or an I2C RTC), which
by default uses line frequency, and ALSO an LTC (or line time clock)
interrupt source of "jiffies"

CTSS (the progenitor of both Multics and DEC timesharing systems) had
a "chronolog" device (attached as a magtape drive?) that supplied the
current time, month and day (but not year!), while even large (million
dollar) DEC timesharing systems in the 1970's and 80's expected a
human operator to be present to enter the date and time.

But I can understand AT&T wanting embedded billing systems to have
good timestamps!

I wonder: Was the VAX 11/780 the first DEC system that came with an
RTC/TOY clock out of the box?

From tuhs at tuhs.org  Thu May  7 04:19:58 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Wed, 6 May 2026 14:19:58 -0400
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
Message-ID: <CAC20D2M49mGfaxsRuuuS-YBGF7397w4OAx+Pfe7DZVsGyrHL+Q@mail.gmail.com>

On Wed, May 6, 2026 at 4:12 AM Thalia Archibald via TUHS <tuhs at tuhs.org>
wrote:

>
>
> Was there a precedent for the choice of sixtieths of a second?
>
Yes, DEC used line frequency from very early on in their processors.  For
the original PDP-11s (/20, 40, 45, 70), the KW11-L  (not be confused with
the KW-11P) was a single high card
http://www.bitsavers.org/pdf/dec/pdp11/1140/EK-KW11L_TM-002_KW11-L_Line_Time_Clock_Manual_Jul74.pdf
 [there is a picture of in on gunkies:
https://gunkies.org/wiki/KW11-L_Line_Time_Clock ], the functionality was
added to the DL11-W, so when it was used as the console KL11 it also acted
as a KW11-L



The purpose is to produce interrupts at a rate of 50 or 60 Hz, driven from
the AC power provided to the CPU's power supply [which is why UNIX is
configured appropriately].

If I understand the history correctly, the PDP-5 (1963): is the first DEC
machine to offer a Type 137 Real Time Clock, which could be configured to
trigger interrupts at the power line frequency (60Hz or 50Hz). This design
directly influenced the later PDP-8. PDP-8 (1965): Supported the DK8-EA
(and later the DK8-L and DK8-P) real-time clocks. The DK8-L Line Frequency
Clock was functionally identical to the KW11-L, providing a flag and
interrupt every 16.6ms or 20ms.   PDP-6 (1964): As a large-scale system, it
had a central clock (the Type 701) that provided several fixed frequencies,
including a line frequency signal for system timekeeping.   PDP-7 (1965):
Offered the Type 175 or Type 144 real-time clocks.   Like the PDP-5, these
could be set to line frequency for basic task scheduling.

From tuhs at tuhs.org  Thu May  7 05:59:01 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Wed, 6 May 2026 15:59:01 -0400
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <202605061813.646IDYhk082929@ultimate.com>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <20260506083214.un4cgnw7xzkevbm3@illithid>
 <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>
 <202605061725.646HPaad081924@ultimate.com>
 <F6Zh5b_8SlGe1KNMLxJwCPXcawdW30tvWijmsrUiQ9Nb3q8_4xUlKFTsfg04Dga9ImYSYXDUVVv_CJ1fQrUoK0-mo_FkfhQ7h5DzMzWd9GI=@protonmail.com>
 <202605061813.646IDYhk082929@ultimate.com>
Message-ID: <CAC20D2M5xRd0hHnY9ryARJW3MVfjrQ4xQ5kADFHrUgZFdtrkZQ@mail.gmail.com>

On Wed, May 6, 2026 at 2:13 PM Phil Budne via TUHS <tuhs at tuhs.org> wrote:

> I wonder: Was the VAX 11/780 the first DEC system that came with an
> RTC/TOY clock out of the box?
>
Sort of.  It was not battery-backed up, which is why both VMS and UNIX
require the time to be set.  IIRC first Vaxen to have a battery to cover
the TOY on a power outage,  were the Mayflower machines  (uVax and
VaxStation systems).  The J-11-based systems had a TOY, as did the 23+ (not
the 23).

FWIW: I've been trying to get Supnik to allow support for them into SIMH
and then set via the host.  Bob's solution is when you start SIMH, it
assume is was from power-off, which is supported by all OS's on all models
of both.

From tuhs at tuhs.org  Thu May  7 06:51:07 2026
From: tuhs at tuhs.org (Kevin Bowling via TUHS)
Date: Wed, 6 May 2026 13:51:07 -0700
Subject: [TUHS] [off-topic] Anyone still using USENET?
In-Reply-To: <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>
References: <202301270853.30R8rif6014271@freefriends.org>
 <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>
Message-ID: <CAK7dMtAs_UYQqK_WpGt68+D_PwCvkTRjtE0gkoRwB=4pGhN4qw@mail.gmail.com>

On Fri, Jan 27, 2023 at 5:23 PM Kevin Bowling <kevin.bowling at kev009.com> wrote:
>
>
>
> On Fri, Jan 27, 2023 at 1:54 AM <arnold at skeeve.com> wrote:
>>
>> Hi.
>>
>> I've been using trn for decades to read a very few USENET groups. Until recently I've
>> been using aioe.org as my NNTP server but it seems to have gone dark. Before that
>> I used eternal-september.org, but when I try that I now get:
>>
>> | $ NNTPSERVER=news.eternal-september.org trn
>> | Connecting to news.eternal-september.org...Done.
>> |
>> | Invalid (bogus) newsgroup found: comp.sys.3b1
>> |
>> | Invalid (bogus) newsgroup found: comp.sources.bugs
>> |
>> | Invalid (bogus) newsgroup found: comp.misc
>> |
>> | Invalid (bogus) newsgroup found: comp.compilers
>> | ....
>>
>> And those all are (or were!) valid groups. If anyone has suggestions for a good
>> free NNTP server, please let me know. Privately is fine.  I'm at a bit of
>> a loss otherwise.
>
>
> I maintain inn and some related ports for FreeBSD.  I run a public server at csiph.com and am happy to provide accounts or peering to interested parties.  Read access is open.

I am working on a new thing http://csiph.com/groups.  Search indexing is
currently paused while I move storage to enterprise flash but covers
up through comp.*

History is about 10-20 years deep depending on the hierarchy.  I still
need to figure out how to back fill everything, the goal is to fully
replace Google Groups for historical research.

>
>>
>> Thanks,
>>
>> Arnold

From tuhs at tuhs.org  Thu May  7 08:22:51 2026
From: tuhs at tuhs.org (babydr DBA James W. Laferriere via TUHS)
Date: Wed, 6 May 2026 14:22:51 -0800 (AKDT)
Subject: [TUHS] [off-topic] Anyone still using USENET?
In-Reply-To: <CAK7dMtAs_UYQqK_WpGt68+D_PwCvkTRjtE0gkoRwB=4pGhN4qw@mail.gmail.com>
References: <202301270853.30R8rif6014271@freefriends.org>
 <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>
 <CAK7dMtAs_UYQqK_WpGt68+D_PwCvkTRjtE0gkoRwB=4pGhN4qw@mail.gmail.com>
Message-ID: <809651a3-42be-e680-3eee-ad885dcfffdf@baby-dragons.com>

 	Thank You ,   Kevin .  JimL

-- 
+---------------------------------------------------------------------+
| James   W.   Laferriere    | System    Techniques | Give me VMS     |
| Network & System Engineer  | 3237     Holden Road |  Give me Linux  |
| jiml at system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+---------------------------------------------------------------------+

From tuhs at tuhs.org  Thu May  7 08:49:35 2026
From: tuhs at tuhs.org (Erik E. Fair via TUHS)
Date: Wed, 06 May 2026 15:49:35 -0700
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <CAC20D2M5xRd0hHnY9ryARJW3MVfjrQ4xQ5kADFHrUgZFdtrkZQ@mail.gmail.com>
References: <202605061813.646IDYhk082929@ultimate.com>
Message-ID: <5088.1778107775@cesium.clock.org>

I have a tickle in my memory that the Unix V7 (or 2BSD?) answer to a lack of battery-backed ToD/ToY RTC was using the last modify date of inode #2 in the root filesystem as "close enough for government work" precisely because that'd be the last one modified in a clean shutdown, and definitely better than starting time_t zero (epoch: 00:00 Jan 1 1970 GMT).

There was also the issue for many years of having to kill cron before doing a big delta time change: cron would wake up suddenly hours or days later than it thought the last time it had run, and would spawn all work it needed to run to "catch up" ...

	Erik

From tuhs at tuhs.org  Thu May  7 09:14:21 2026
From: tuhs at tuhs.org (Warner Losh via TUHS)
Date: Wed, 6 May 2026 17:14:21 -0600
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <5088.1778107775@cesium.clock.org>
References: <202605061813.646IDYhk082929@ultimate.com>
 <CAC20D2M5xRd0hHnY9ryARJW3MVfjrQ4xQ5kADFHrUgZFdtrkZQ@mail.gmail.com>
 <5088.1778107775@cesium.clock.org>
Message-ID: <CANCZdfqym68MuSBf80QNinuS8yb-wU52sSjAvMdiYnMpM5686g@mail.gmail.com>

On Wed, May 6, 2026, 4:49 PM Erik E. Fair via TUHS <tuhs at tuhs.org> wrote:

> I have a tickle in my memory that the Unix V7 (or 2BSD?) answer to a lack
> of battery-backed ToD/ToY RTC was using the last modify date of inode #2 in
> the root filesystem as "close enough for government work" precisely because
> that'd be the last one modified in a clean shutdown, and definitely better
> than starting time_t zero (epoch: 00:00 Jan 1 1970 GMT).
>

BSD does that to this day.

Warner


There was also the issue for many years of having to kill cron before doing
> a big delta time change: cron would wake up suddenly hours or days later
> than it thought the last time it had run, and would spawn all work it
> needed to run to "catch up" ...
>
>         Erik
>

From tuhs at tuhs.org  Thu May  7 11:20:43 2026
From: tuhs at tuhs.org (John Levine via TUHS)
Date: 6 May 2026 21:20:43 -0400
Subject: [TUHS] [off-topic] Anyone still using USENET?
In-Reply-To: <CAK7dMtAs_UYQqK_WpGt68+D_PwCvkTRjtE0gkoRwB=4pGhN4qw@mail.gmail.com>
References: <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>
 <202301270853.30R8rif6014271@freefriends.org>
 <CAK7dMtAs_UYQqK_WpGt68+D_PwCvkTRjtE0gkoRwB=4pGhN4qw@mail.gmail.com>
Message-ID: <20260507012043.6552B1086AB32@ary.qy>

>>> | Connecting to news.eternal-september.org...Done.
>>> |
>>> | Invalid (bogus) newsgroup found: comp.sys.3b1
>>> |
>>> | Invalid (bogus) newsgroup found: comp.sources.bugs
>>> |
>>> | Invalid (bogus) newsgroup found: comp.misc
>>> |
>>> | Invalid (bogus) newsgroup found: comp.compilers

I still moderate comp.compilers and feed it directly to eternal-september.
You must have misconfigured something.

R's,
JOhn

From tuhs at tuhs.org  Thu May  7 11:23:19 2026
From: tuhs at tuhs.org (Dan Cross via TUHS)
Date: Wed, 6 May 2026 21:23:19 -0400
Subject: [TUHS] [off-topic] Anyone still using USENET?
In-Reply-To: <20260507012043.6552B1086AB32@ary.qy>
References: <CAK7dMtB8ZWT6_WSaY12Ti_Qo3Z=_fUNHT07+1kY795X+6REjYQ@mail.gmail.com>
 <202301270853.30R8rif6014271@freefriends.org>
 <CAK7dMtAs_UYQqK_WpGt68+D_PwCvkTRjtE0gkoRwB=4pGhN4qw@mail.gmail.com>
 <20260507012043.6552B1086AB32@ary.qy>
Message-ID: <CAEoi9W6D7AghRfWEE+TwRTZpZmBBWAK8LBaEv5YC2HAE7-x+cQ@mail.gmail.com>

On Wed, May 6, 2026 at 9:20 PM John Levine via TUHS <tuhs at tuhs.org> wrote:
> >>> | Connecting to news.eternal-september.org...Done.
> >>> |
> >>> | Invalid (bogus) newsgroup found: comp.sys.3b1
> >>> |
> >>> | Invalid (bogus) newsgroup found: comp.sources.bugs
> >>> |
> >>> | Invalid (bogus) newsgroup found: comp.misc
> >>> |
> >>> | Invalid (bogus) newsgroup found: comp.compilers
>
> I still moderate comp.compilers and feed it directly to eternal-september.
> You must have misconfigured something.

>From the earlier quoted text, the error messages above were from 2023.

        - Dan C.

From tuhs at tuhs.org  Thu May  7 23:27:52 2026
From: tuhs at tuhs.org (Paul Winalski via TUHS)
Date: Thu, 7 May 2026 09:27:52 -0400
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <CAC20D2M5xRd0hHnY9ryARJW3MVfjrQ4xQ5kADFHrUgZFdtrkZQ@mail.gmail.com>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <20260506083214.un4cgnw7xzkevbm3@illithid>
 <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>
 <202605061725.646HPaad081924@ultimate.com>
 <F6Zh5b_8SlGe1KNMLxJwCPXcawdW30tvWijmsrUiQ9Nb3q8_4xUlKFTsfg04Dga9ImYSYXDUVVv_CJ1fQrUoK0-mo_FkfhQ7h5DzMzWd9GI=@protonmail.com>
 <202605061813.646IDYhk082929@ultimate.com>
 <CAC20D2M5xRd0hHnY9ryARJW3MVfjrQ4xQ5kADFHrUgZFdtrkZQ@mail.gmail.com>
Message-ID: <CABH=_VTRpRzaADFb9vnODiu3WqdZoTDCG4G5h3P4eUNAxSHYHQ@mail.gmail.com>

On Wed, May 6, 2026 at 3:59 PM Clem Cole via TUHS <tuhs at tuhs.org> wrote:

> On Wed, May 6, 2026 at 2:13 PM Phil Budne via TUHS <tuhs at tuhs.org> wrote:
>
> > I wonder: Was the VAX 11/780 the first DEC system that came with an
> > RTC/TOY clock out of the box?
> >
> Sort of.  It was not battery-backed up, which is why both VMS and UNIX
> require the time to be set.  IIRC first Vaxen to have a battery to cover
> the TOY on a power outage,  were the Mayflower machines  (uVax and
> VaxStation systems).  The J-11-based systems had a TOY, as did the 23+ (not
> the 23).
>
> On the 11/780 there was an optional battery backup available that allowed
the PDP-11/03-based console subsystem to maintain the TOY clock when the
system is powered down.  The 11/75
0 also had an optional battery backup for the TOY clock.

TOY clock battery backup was not available on the 11/730.  This prompted
Dick Hustvedt, chief VAX/VMS development engineer, to play a brilliant
April Fools prank.  On April 1 the VMS Group's 11/730 had a new
peripheral.  It was a sundial on a stand.  There was a photocell positioned
at the 12 o'clock position.  The sundial was plugged into the 11/730's
UNIBUS adapter.  On the sundial was a very authentic-looking (it was made
using the actual fonts and layout) DEC marketing brochure claiming the
device to be an "SD730 Fixed Head Solar Horologue".  This device could
detect noon and set the 11/730's TOY clock accordingly.

-Paul W.

From tuhs at tuhs.org  Fri May  8 00:13:14 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Thu, 7 May 2026 10:13:14 -0400
Subject: [TUHS] DECtapes under the UNIX room floor
In-Reply-To: <CABH=_VTRpRzaADFb9vnODiu3WqdZoTDCG4G5h3P4eUNAxSHYHQ@mail.gmail.com>
References: <98F84673-74C5-4C38-8078-05B1452113C5@archibald.dev>
 <afrYX6jMY/QHv4Xg@minnie.tuhs.org>
 <DAEF835C-B004-4BB6-8345-5D00818093F2@archibald.dev>
 <20260506083214.un4cgnw7xzkevbm3@illithid>
 <CAD2gp_R_0iFBD+O0B=vvT87mp_dY1P-gpqO8iDS0iODyFU4HKw@mail.gmail.com>
 <202605061725.646HPaad081924@ultimate.com>
 <F6Zh5b_8SlGe1KNMLxJwCPXcawdW30tvWijmsrUiQ9Nb3q8_4xUlKFTsfg04Dga9ImYSYXDUVVv_CJ1fQrUoK0-mo_FkfhQ7h5DzMzWd9GI=@protonmail.com>
 <202605061813.646IDYhk082929@ultimate.com>
 <CAC20D2M5xRd0hHnY9ryARJW3MVfjrQ4xQ5kADFHrUgZFdtrkZQ@mail.gmail.com>
 <CABH=_VTRpRzaADFb9vnODiu3WqdZoTDCG4G5h3P4eUNAxSHYHQ@mail.gmail.com>
Message-ID: <CAC20D2Nk49aYV5mhWRoAnRyy_Kwq4bxj4_RS1+hWusF1n11dVw@mail.gmail.com>

On Thu, May 7, 2026 at 9:28 AM Paul Winalski <paul.winalski at gmail.com>
wrote:

> TOY clock battery backup was not available on the 11/730.  This prompted
> Dick Hustvedt, chief VAX/VMS development engineer, to play a brilliant
> April Fools prank.  On April 1 the VMS Group's 11/730 had a new
> peripheral.  It was a sundial on a stand.  There was a photocell positioned
> at the 12 o'clock position.  The sundial was plugged into the 11/730's
> UNIBUS adapter.  On the sundial was a very authentic-looking (it was made
> using the actual fonts and layout) DEC marketing brochure claiming the
> device to be an "SD730 Fixed Head Solar Horologue".  This device could
> detect noon and set the 11/730's TOY clock accordingly.
>
And for those readers who never had the pleasure of having a meeting in
ZK03 and seeing it, "SD730 Fixed Head Solar Horologue", along with the
brochure, lived in his memory in a clear plexiglass display in a conference
room.  After Compaq sold the building, I sometimes wondered what happened
to it and to some of the interesting artifacts that decorated each
conference room, each of which had been named after a famous Mathematician
or Computer Scientist, rather than numbered.

Clem

From tuhs at tuhs.org  Fri May  8 09:55:33 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Thu, 07 May 2026 23:55:33 +0000
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
Message-ID: <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>

Received a question from Thalia Archibald concerning my use of the
nomenclature "PG3" vs Pirzada's "Gen3.0".  I pulled together the info
below, seems like it might be interesting to the broader audience:

So it's a bit fuzzy when you get into the weeds. This document[1]
defines the acronym "PG" as such:

> At the highest level in the document hierarchy is the
> Program Document (PG) Index that lists all of the documents
> associated with a program generic.  A single PG-level directory
> occupies the corresponding position in the file system hierarchy.

So within their source control structure you would have directories:

pg-1c300-01 (issue 1)
pg-1c300-02 (issue 2)

And then under those the "PR" directories containing the individual
groupings of source files, other documents, etc.

This isn't what I originally based my use of this acronym on though,
rather just Program Generic (PG).
Typically if I do see a shorter name,
the system is just referred to as a "Generic", proper noun. This was
common practice within AT&T and did not just apply to UNIX[2][3].
In fact, this first round of USG UNIX (before UNIX/TS and later) was
very "Bell-ish" compared to later efforts. The manuals were the only
ones rendered to Bell System standards in that they had the OSD headers
with document ID, issue, date, etc. rather than just the standard
manpage masthead. Several of the USG documents of the time look like
the same typesetting package used for 3ESS generic pidents for instance.

As I was gathering some of this info, I keep seeing PG-1C300 used where
the system is referred to in short.  This actually makes sense given
AT&T's use of the "PG" prefix for a number of different projects.
For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built
on UNIX by WECo for a frame system in telco offices[5], has
documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix
for the underlying generic. Outside of UNIX, PG-3H903 is one of the
3ESS generics[6].

After compiling all of that info, I'm inclined to say that the
"canonical" names in increasing length are "PG-1C300", then "Generic",
then "Program Generic". I would think given Pirzada's being at AT&T
at the time though the "Gen3.0" etc. nomenclature would also be
acceptable, just maybe not "period".

- Matt G.

P.S. As always this is just my own research, I wasn't there so I'd
certainly get some second opinions if available.

[1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf
[2] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf
[3] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf
[4] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs 01-02 Title Page.pdf
[5] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf
[6] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf

From tuhs at tuhs.org  Fri May  8 09:59:05 2026
From: tuhs at tuhs.org (Thalia Archibald via TUHS)
Date: Thu, 07 May 2026 23:59:05 +0000
Subject: [TUHS] Name of UNIX Program Generic
Message-ID: <07D15E88-55C3-42C3-87D5-0B24D5CDF26F@archibald.dev>

What was the common shorthand for UNIX Program Generic Issue 3?
Generic 3.0, as Pirzada refers to it [0]?
"UNIX PG-1C300 Issue 3”, as it identifies itself in /usr/sys/lib1?
PG3, as chosen for our recent release of the tapes?

Why was UNIX Program Generic called something so, well, generic?
Is it part of a larger naming scheme?

Thalia

[0]: https://www.tuhs.org/Archive/Documentation/Theses/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf

From tuhs at tuhs.org  Fri May  8 10:11:38 2026
From: tuhs at tuhs.org (Larry McVoy via TUHS)
Date: Thu, 7 May 2026 17:11:38 -0700
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
Message-ID: <20260508001138.GE25310@mcvoy.com>

I've never heard of PG3.  Is this something like the SVID or something else?

On Thu, May 07, 2026 at 11:55:33PM +0000, segaloco via TUHS wrote:
> Received a question from Thalia Archibald concerning my use of the
> nomenclature "PG3" vs Pirzada's "Gen3.0".  I pulled together the info
> below, seems like it might be interesting to the broader audience:
> 
> So it's a bit fuzzy when you get into the weeds. This document[1]
> defines the acronym "PG" as such:
> 
> > At the highest level in the document hierarchy is the
> > Program Document (PG) Index that lists all of the documents
> > associated with a program generic.  A single PG-level directory
> > occupies the corresponding position in the file system hierarchy.
> 
> So within their source control structure you would have directories:
> 
> pg-1c300-01 (issue 1)
> pg-1c300-02 (issue 2)
> 
> And then under those the "PR" directories containing the individual
> groupings of source files, other documents, etc.
> 
> This isn't what I originally based my use of this acronym on though,
> rather just Program Generic (PG).
> Typically if I do see a shorter name,
> the system is just referred to as a "Generic", proper noun. This was
> common practice within AT&T and did not just apply to UNIX[2][3].
> In fact, this first round of USG UNIX (before UNIX/TS and later) was
> very "Bell-ish" compared to later efforts. The manuals were the only
> ones rendered to Bell System standards in that they had the OSD headers
> with document ID, issue, date, etc. rather than just the standard
> manpage masthead. Several of the USG documents of the time look like
> the same typesetting package used for 3ESS generic pidents for instance.
> 
> As I was gathering some of this info, I keep seeing PG-1C300 used where
> the system is referred to in short.  This actually makes sense given
> AT&T's use of the "PG" prefix for a number of different projects.
> For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built
> on UNIX by WECo for a frame system in telco offices[5], has
> documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix
> for the underlying generic. Outside of UNIX, PG-3H903 is one of the
> 3ESS generics[6].
> 
> After compiling all of that info, I'm inclined to say that the
> "canonical" names in increasing length are "PG-1C300", then "Generic",
> then "Program Generic". I would think given Pirzada's being at AT&T
> at the time though the "Gen3.0" etc. nomenclature would also be
> acceptable, just maybe not "period".
> 
> - Matt G.
> 
> P.S. As always this is just my own research, I wasn't there so I'd
> certainly get some second opinions if available.
> 
> [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf
> [2] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf
> [3] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf
> [4] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs 01-02 Title Page.pdf
> [5] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf
> [6] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

From tuhs at tuhs.org  Fri May  8 10:12:54 2026
From: tuhs at tuhs.org (Thalia Archibald via TUHS)
Date: Fri, 08 May 2026 00:12:54 +0000
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
Message-ID: <76759356-BBDB-4234-A341-4850CC135029@archibald.dev>

Interestingly, Pirzada calls it “issue 1 of UNIX Operating System Generic
PG-1C300”, never “Program Generic”.

These are the Generic releases mentioned by Pirzada:
- USG release 1.0 (15 December 1973)
- PG-1C300 issue 1: USG release 2 mod level 2.24 (April 1974)
- PG-1C300 issue 2: USG system at mod level 3.33 (January 1976) 
- PG-1C300 issue 3 (spring 1977)

Additionally with the same number scheme:
- PG-1C600: MERT Release 0 (November 1977)

Thalia

> On May 7, 2026, at 16:55, segaloco via TUHS <tuhs at tuhs.org> wrote:
> 
> Received a question from Thalia Archibald concerning my use of the
> nomenclature "PG3" vs Pirzada's "Gen3.0".  I pulled together the info
> below, seems like it might be interesting to the broader audience:
> 
> So it's a bit fuzzy when you get into the weeds. This document[1]
> defines the acronym "PG" as such:
> 
>> At the highest level in the document hierarchy is the
>> Program Document (PG) Index that lists all of the documents
>> associated with a program generic.  A single PG-level directory
>> occupies the corresponding position in the file system hierarchy.
> 
> So within their source control structure you would have directories:
> 
> pg-1c300-01 (issue 1)
> pg-1c300-02 (issue 2)
> 
> And then under those the "PR" directories containing the individual
> groupings of source files, other documents, etc.
> 
> This isn't what I originally based my use of this acronym on though,
> rather just Program Generic (PG).
> Typically if I do see a shorter name,
> the system is just referred to as a "Generic", proper noun. This was
> common practice within AT&T and did not just apply to UNIX[2][3].
> In fact, this first round of USG UNIX (before UNIX/TS and later) was
> very "Bell-ish" compared to later efforts. The manuals were the only
> ones rendered to Bell System standards in that they had the OSD headers
> with document ID, issue, date, etc. rather than just the standard
> manpage masthead. Several of the USG documents of the time look like
> the same typesetting package used for 3ESS generic pidents for instance.
> 
> As I was gathering some of this info, I keep seeing PG-1C300 used where
> the system is referred to in short.  This actually makes sense given
> AT&T's use of the "PG" prefix for a number of different projects.
> For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built
> on UNIX by WECo for a frame system in telco offices[5], has
> documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix
> for the underlying generic. Outside of UNIX, PG-3H903 is one of the
> 3ESS generics[6].
> 
> After compiling all of that info, I'm inclined to say that the
> "canonical" names in increasing length are "PG-1C300", then "Generic",
> then "Program Generic". I would think given Pirzada's being at AT&T
> at the time though the "Gen3.0" etc. nomenclature would also be
> acceptable, just maybe not "period".
> 
> - Matt G.
> 
> P.S. As always this is just my own research, I wasn't there so I'd
> certainly get some second opinions if available.
> 
> [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf
> [2] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf
> [3] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf
> [4] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs 01-02 Title Page.pdf
> [5] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf
> [6] - https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf



From tuhs at tuhs.org  Fri May  8 11:19:38 2026
From: tuhs at tuhs.org (Warner Losh via TUHS)
Date: Thu, 7 May 2026 19:19:38 -0600
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <76759356-BBDB-4234-A341-4850CC135029@archibald.dev>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <76759356-BBDB-4234-A341-4850CC135029@archibald.dev>
Message-ID: <CANCZdfpgu+kmJza_-VTbct5QnzpvTLyYCT0BnahM_5a7dACvFQ@mail.gmail.com>

"USG mod level 3.33" might be the best moniker.

Unix Operating System Generic makes the most sense to me, since Bell
entities would take that and turn it into the specific OS for their switch,
billing system, etc. USG curated the research products into something that
people could use.

Warner


On Thu, May 7, 2026, 6:13 PM Thalia Archibald via TUHS <tuhs at tuhs.org>
wrote:

> Interestingly, Pirzada calls it “issue 1 of UNIX Operating System Generic
> PG-1C300”, never “Program Generic”.
>
> These are the Generic releases mentioned by Pirzada:
> - USG release 1.0 (15 December 1973)
> - PG-1C300 issue 1: USG release 2 mod level 2.24 (April 1974)
> - PG-1C300 issue 2: USG system at mod level 3.33 (January 1976)
> - PG-1C300 issue 3 (spring 1977)
>
> Additionally with the same number scheme:
> - PG-1C600: MERT Release 0 (November 1977)
>
> Thalia
>
> > On May 7, 2026, at 16:55, segaloco via TUHS <tuhs at tuhs.org> wrote:
> >
> > Received a question from Thalia Archibald concerning my use of the
> > nomenclature "PG3" vs Pirzada's "Gen3.0".  I pulled together the info
> > below, seems like it might be interesting to the broader audience:
> >
> > So it's a bit fuzzy when you get into the weeds. This document[1]
> > defines the acronym "PG" as such:
> >
> >> At the highest level in the document hierarchy is the
> >> Program Document (PG) Index that lists all of the documents
> >> associated with a program generic.  A single PG-level directory
> >> occupies the corresponding position in the file system hierarchy.
> >
> > So within their source control structure you would have directories:
> >
> > pg-1c300-01 (issue 1)
> > pg-1c300-02 (issue 2)
> >
> > And then under those the "PR" directories containing the individual
> > groupings of source files, other documents, etc.
> >
> > This isn't what I originally based my use of this acronym on though,
> > rather just Program Generic (PG).
> > Typically if I do see a shorter name,
> > the system is just referred to as a "Generic", proper noun. This was
> > common practice within AT&T and did not just apply to UNIX[2][3].
> > In fact, this first round of USG UNIX (before UNIX/TS and later) was
> > very "Bell-ish" compared to later efforts. The manuals were the only
> > ones rendered to Bell System standards in that they had the OSD headers
> > with document ID, issue, date, etc. rather than just the standard
> > manpage masthead. Several of the USG documents of the time look like
> > the same typesetting package used for 3ESS generic pidents for instance.
> >
> > As I was gathering some of this info, I keep seeing PG-1C300 used where
> > the system is referred to in short.  This actually makes sense given
> > AT&T's use of the "PG" prefix for a number of different projects.
> > For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built
> > on UNIX by WECo for a frame system in telco offices[5], has
> > documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix
> > for the underlying generic. Outside of UNIX, PG-3H903 is one of the
> > 3ESS generics[6].
> >
> > After compiling all of that info, I'm inclined to say that the
> > "canonical" names in increasing length are "PG-1C300", then "Generic",
> > then "Program Generic". I would think given Pirzada's being at AT&T
> > at the time though the "Gen3.0" etc. nomenclature would also be
> > acceptable, just maybe not "period".
> >
> > - Matt G.
> >
> > P.S. As always this is just my own research, I wasn't there so I'd
> > certainly get some second opinions if available.
> >
> > [1] -
> https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf
> > [2] -
> https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf
> > [3] -
> https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf
> > [4] -
> https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs
> 01-02 Title Page.pdf
> > [5] -
> https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf
> > [6] -
> https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf
>
>
>

From tuhs at tuhs.org  Fri May  8 11:24:46 2026
From: tuhs at tuhs.org (Jonathan Gray via TUHS)
Date: Fri, 8 May 2026 11:24:46 +1000
Subject: [TUHS] Name of UNIX Program Generic
In-Reply-To: <07D15E88-55C3-42C3-87D5-0B24D5CDF26F@archibald.dev>
References: <07D15E88-55C3-42C3-87D5-0B24D5CDF26F@archibald.dev>
Message-ID: <af07XjGT0ltpGFEm@largo.jsg.id.au>

On Thu, May 07, 2026 at 11:59:05PM +0000, Thalia Archibald via TUHS wrote:
> What was the common shorthand for UNIX Program Generic Issue 3?
> Generic 3.0, as Pirzada refers to it [0]?

"Generic 3" has some usage as well:

"This version of the Unix Programmer's Manual is essentially the
Program Generic 3 Edition (March 1977) with update pages"
G.W.R.L. - preface to MERT Release 0, Unix Programmer's Manual
October 1977
...
"List of Update Pages for Unix Generic 3"

"This document describes differences users may encounter when changing
to UNIX/TS Edition 1.0 from the last release of the C compiler shipped
for Generic 3."
Andrew Koenig - Changes in the C Environment for UNIX/TS Edition 1.0
September 27, 1978
https://archive.org/details/AUUGN_V01_3/page/n18/mode/1up
AUUGN Vol 1, No 3, Feb-Mar 1979, pp 19-24

"PDP-11/70 computer results prior to 1980 are for the Generic 3
(PG 1C-300) UNIX system version"
J. Feder - The Evolution of UNIX System Performance
BSTJ Vol 63, No 8, October 1984, pp 1791-1814

"USG Generic 3"
John Mashey
net.unix-wizards, Xenix286 Wonders, Bugs, and Patches..., May 9, 1985
https://www.tuhs.org/Usenet/comp.unix.wizards/1985-May/008079.html

"We put together the UNIX Support Group [USG] in September of 1973 and
released the first C version of UNIX internally. [Generic I, II, and III
were produced by these initial efforts.]"
Berkley Tague interviewed by Ned Peirce
Unix Review, Vol 3, No 6, June 1985, p 61
https://archive.org/details/Unix_Review_1985_Jun.pdf/page/n61/mode/2up

From tuhs at tuhs.org  Fri May  8 11:25:07 2026
From: tuhs at tuhs.org (Thalia Archibald via TUHS)
Date: Fri, 08 May 2026 01:25:07 +0000
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <CANCZdfpgu+kmJza_-VTbct5QnzpvTLyYCT0BnahM_5a7dACvFQ@mail.gmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <76759356-BBDB-4234-A341-4850CC135029@archibald.dev>
 <CANCZdfpgu+kmJza_-VTbct5QnzpvTLyYCT0BnahM_5a7dACvFQ@mail.gmail.com>
Message-ID: <276F297B-CF32-407A-9C3D-00C1CCCAADC1@archibald.dev>

On May 7, 2026, at 18:19, Warner Losh <imp at bsdimp.com> wrote:
> On Thu, May 7, 2026, 6:13 PM Thalia Archibald via TUHS <tuhs at tuhs.org> wrote:
>> These are the Generic releases mentioned by Pirzada:
>> - USG release 1.0 (15 December 1973)
>> - PG-1C300 issue 1: USG release 2 mod level 2.24 (April 1974)
>> - PG-1C300 issue 2: USG system at mod level 3.33 (January 1976) 
>> - PG-1C300 issue 3 (spring 1977)
> 
> "USG mod level 3.33" might be the best moniker.

Note that the USG release number is one off from the Generic issue number,
so mod level 3.33 corresponds to issue 2, not issue 3.
Pirzada does not list the mod level for issue 3.

Thalia

From tuhs at tuhs.org  Fri May  8 11:30:39 2026
From: tuhs at tuhs.org (Warner Losh via TUHS)
Date: Thu, 7 May 2026 19:30:39 -0600
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <276F297B-CF32-407A-9C3D-00C1CCCAADC1@archibald.dev>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <76759356-BBDB-4234-A341-4850CC135029@archibald.dev>
 <CANCZdfpgu+kmJza_-VTbct5QnzpvTLyYCT0BnahM_5a7dACvFQ@mail.gmail.com>
 <276F297B-CF32-407A-9C3D-00C1CCCAADC1@archibald.dev>
Message-ID: <CANCZdfoDSH=juuVHoK=WJhJEX7S9FW8emAgm__6yHioietC6kA@mail.gmail.com>

On Thu, May 7, 2026, 7:25 PM Thalia Archibald <thalia at archibald.dev> wrote:

> On May 7, 2026, at 18:19, Warner Losh <imp at bsdimp.com> wrote:
> > On Thu, May 7, 2026, 6:13 PM Thalia Archibald via TUHS <tuhs at tuhs.org>
> wrote:
> >> These are the Generic releases mentioned by Pirzada:
> >> - USG release 1.0 (15 December 1973)
> >> - PG-1C300 issue 1: USG release 2 mod level 2.24 (April 1974)
> >> - PG-1C300 issue 2: USG system at mod level 3.33 (January 1976)
> >> - PG-1C300 issue 3 (spring 1977)
> >
> > "USG mod level 3.33" might be the best moniker.
>
> Note that the USG release number is one off from the Generic issue number,
> so mod level 3.33 corresponds to issue 2, not issue 3.
> Pirzada does not list the mod level for issue 3.
>

Fair point. I see other emal call it Generic 3... and a few other names...
I thought it was easy until I saw them.

Warner

>

From tuhs at tuhs.org  Fri May  8 11:48:38 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Fri, 08 May 2026 01:48:38 +0000
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <CANCZdfpgu+kmJza_-VTbct5QnzpvTLyYCT0BnahM_5a7dACvFQ@mail.gmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <76759356-BBDB-4234-A341-4850CC135029@archibald.dev>
 <CANCZdfpgu+kmJza_-VTbct5QnzpvTLyYCT0BnahM_5a7dACvFQ@mail.gmail.com>
Message-ID: <meDUKhbKmOvFeJM-1Hny4R32CT6sXmfoSdqYnVpZBeDyVTB9thpzY8c8FX1VUBERaPeipZb6cqQU6AjoZum_Kd8ZaaX7QhnayA7naYp0njo=@protonmail.com>

On Thursday, May 7th, 2026 at 18:19, Warner Losh via TUHS <tuhs at tuhs.org> wrote:

> "USG mod level 3.33" might be the best moniker.
> 
> Unix Operating System Generic makes the most sense to me, since Bell
> entities would take that and turn it into the specific OS for their switch,
> billing system, etc. USG curated the research products into something that
> people could use.
> 
> Warner
>

Pirzada's thesis gives these timeframes for USG's initial version:

73-12-15 - USG Release 1.0
74-04-?? - USG Release 2.0
74-11-?? - USG Release 2 mod 2.24 (PG Issue 1)
76-01-?? - USG Release 3.0 mod 3.33 (PG Issue 2)
77-03-?? - USG PG Issue 3 (No Release or mod number given).

So there was the release mod level and the issue of the generic.  This dual versioning scheme also appears in CB-UNIX, which has manuals featuring "Editions" like 2.1, 2.3, but then a kernel featuring "releases" like 2 and 3.  I've documented this situation a bit in the wiki here:

https://wiki.tuhs.org/doku.php?id=systems:cb1

By the way just to summarize since I've made a lot of noise about it but maybe haven't explained the basics: Program Generic Issue 3, or PG3 as I've been calling it, is the last "supported" USG release inside AT&T prior to reorganization of USG's efforts behind the UNIX/TS and ongoing PWB projects.  In particular, UNIX Program Generic was intended as a UNIX packaging that met BTL standards.  This made for several pecularities:

- Printed manuals (of which Issue 2 and Issue 3 are the only confirmed widely-printed releases) contained OSDD (Operations Systems Deliverable Documentation) headers, common to other BTL systems documentation in requiring the document code, date, issue number, etc. printed in the outer corner of the page, much like Bell System Practices (BSP) documents.
- The literature and sources themselves were arranged in this PG-, PA-, PD-, etc. nomenclature found in other AT&T projects like switching stuff in Columbus.
- Other AT&T projects built on top of Program Generic then cite it or at least adhere to similar documentation requirements such as COSMOS and MERT Release 0.

So yeah the "USG supported UNIX for the BTL user community" was one part of their responsibilities, but with Program Generic that also expanded to supporting UNIX as a standard AT&T OS for building telco and related systems on top of.  While UNIX was the in-house solution, AT&T also maintained standards for systems development on top of other operating systems such as OS 1100 and VMS.  Some documentation can be found here in BSP section 007 on Information Systems:

https://www.telecomarchive.com/007.html

Anywho, probably enough from the firehose on mid 70s USG activities for now.  I'm just so glad some of this stuff is finally preserved properly and folks are talking about it.  Program Generic in particular is very "Bell-ish" so tickles the overlap between my UNIX and telecom interests well.

- Matt G.

From tuhs at tuhs.org  Fri May  8 12:28:49 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Thu, 7 May 2026 22:28:49 -0400
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <20260508001138.GE25310@mcvoy.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
Message-ID: <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>

Different audiences/different objectives.

PG was a term and efforts directed >>inside<< the Bell System to try to get
their own different and divergent UNIX implementations together in a more
uniform manner.

SVID was much later and directed >>externally<< to folks like you and me.
It was a reaction by USG to /usr/group’s 1985 document, which was
rebirthed/rewritten in IEEE/ANSI style to become P1003.

AT&T has started their ‘consider it standard’ campaign and was very much
miffed that the ‘definition’ of there ‘thing’ was being defined outside of
AT&T and they did not control it.  In fact, there was a big effort to try
to get P1003 to take SVID directly (we pushed back, not nearly hard enough
in my eyes, but that’s a different story).  In fact, ATT never stopped, so
if you look at later editions of you can see more and more influence it had
on later documents.

To complete the thought, SPEC1170 was created when it was realized by the
members of UI (particularly the ISVs), that even with SVID and POSIX it was
still really hard to actually develop large systems oriented SW products
because while system call interface was now fairly well defined, there were
so many other ‘upper level’ interfaces [1170 of them in fact - how it got
its name] within the different UNIX implementations that described how a
system was managed and user encountered a Unix-based system, it was
extremely difficult to create just one version of your product- the test
matrix against all the different favors from SVRx, BSDs, Ultrix, Tru64,
SunOS, Solaris, HPUX, AIX370/RS/PS2, DGUX … you get the idea.


Sent from a handheld expect more typos than usual

On Thu, May 7, 2026 at 8:11 PM Larry McVoy via TUHS <tuhs at tuhs.org> wrote:

> I've never heard of PG3.  Is this something like the SVID or something
> else?
>
> On Thu, May 07, 2026 at 11:55:33PM +0000, segaloco via TUHS wrote:
> > Received a question from Thalia Archibald concerning my use of the
> > nomenclature "PG3" vs Pirzada's "Gen3.0".  I pulled together the info
> > below, seems like it might be interesting to the broader audience:
> >
> > So it's a bit fuzzy when you get into the weeds. This document[1]
> > defines the acronym "PG" as such:
> >
> > > At the highest level in the document hierarchy is the
> > > Program Document (PG) Index that lists all of the documents
> > > associated with a program generic.  A single PG-level directory
> > > occupies the corresponding position in the file system hierarchy.
> >
> > So within their source control structure you would have directories:
> >
> > pg-1c300-01 (issue 1)
> > pg-1c300-02 (issue 2)
> >
> > And then under those the "PR" directories containing the individual
> > groupings of source files, other documents, etc.
> >
> > This isn't what I originally based my use of this acronym on though,
> > rather just Program Generic (PG).
> > Typically if I do see a shorter name,
> > the system is just referred to as a "Generic", proper noun. This was
> > common practice within AT&T and did not just apply to UNIX[2][3].
> > In fact, this first round of USG UNIX (before UNIX/TS and later) was
> > very "Bell-ish" compared to later efforts. The manuals were the only
> > ones rendered to Bell System standards in that they had the OSD headers
> > with document ID, issue, date, etc. rather than just the standard
> > manpage masthead. Several of the USG documents of the time look like
> > the same typesetting package used for 3ESS generic pidents for instance.
> >
> > As I was gathering some of this info, I keep seeing PG-1C300 used where
> > the system is referred to in short.  This actually makes sense given
> > AT&T's use of the "PG" prefix for a number of different projects.
> > For instance, MERT Release 0 is given as PG-1C600[4]. COSMOS, built
> > on UNIX by WECo for a frame system in telco offices[5], has
> > documentation given as PA-6P014, possibly implying a PG-6Pxxx prefix
> > for the underlying generic. Outside of UNIX, PG-3H903 is one of the
> > 3ESS generics[6].
> >
> > After compiling all of that info, I'm inclined to say that the
> > "canonical" names in increasing length are "PG-1C300", then "Generic",
> > then "Program Generic". I would think given Pirzada's being at AT&T
> > at the time though the "Gen3.0" etc. nomenclature would also be
> > acceptable, just maybe not "period".
> >
> > - Matt G.
> >
> > P.S. As always this is just my own research, I wasn't there so I'd
> > certainly get some second opinions if available.
> >
> > [1] -
> https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1099_Program_Generic_Control_and_Documentation_on_UNIX.pdf
> > [2] -
> https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/233/233-154-135_I1.pdf
> > [3] -
> https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/234/234-090-161_I1.pdf
> > [4] -
> https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs
> 01-02 Title Page.pdf
> > [5] -
> https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PA-6P014_I3.pdf
> > [6] -
> https://telecomarchive.s3.us-east-2.amazonaws.com/docs/bsp-archive/SPCS/PG-3H903_I10.pdf
>
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

From tuhs at tuhs.org  Sat May  9 00:25:13 2026
From: tuhs at tuhs.org (Larry McVoy via TUHS)
Date: Fri, 8 May 2026 07:25:13 -0700
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
Message-ID: <20260508142513.GI25310@mcvoy.com>

On Thu, May 07, 2026 at 10:28:49PM -0400, Clem Cole wrote:
> matrix against all the different favors from SVRx, BSDs, Ultrix, Tru64,
> SunOS, Solaris, HPUX, AIX370/RS/PS2, DGUX ??? you get the idea.

With the exception of AIX370/RS/PS2 and DGUX, BitKeeper ran on all of
those and added Linux/370, SGI, MacOS, and all variants of Windows.

It sort of doesn't matter these days but the portability stuff in
that source base is worth a look.

From tuhs at tuhs.org  Sat May  9 01:31:09 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Fri, 8 May 2026 11:31:09 -0400
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <20260508142513.GI25310@mcvoy.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
 <20260508142513.GI25310@mcvoy.com>
Message-ID: <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>

below

On Fri, May 8, 2026 at 10:25 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, May 07, 2026 at 10:28:49PM -0400, Clem Cole wrote:
> > matrix against all the different favors from SVRx, BSDs, Ultrix, Tru64,
> > SunOS, Solaris, HPUX, AIX370/RS/PS2, DGUX ??? you get the idea.
>
> With the exception of AIX370/RS/PS2 and DGUX, BitKeeper ran on all of
> those and added Linux/370, SGI, MacOS, and all variants of Windows.
>
I know it did.  For many (most) programs and tool suites, frankly, POSIX
conformance was all that was needed.  But much larger programs, and often
had tentacles into OS things, such as Oracle, SAP, BAAN, and a slew of CAD
vendors, could not.  BTW: this only got worse with Linux clusters.  For
instance, Fluent (later purchased by ANSYS) had a test matrix of over 144
combinations to get a release out the door at one point.

>
> It sort of doesn't matter these days but the portability stuff in that
> source base is worth a look.
>
Actually, I've found it is now worse than it was during the proprietary
UNIX days, as you know, we have many of the "end-arounds" that traditional
UNIX had. Since the hardware is no longer "single sourced" from Sun, DEC, HP,
or whoever (in the old days, users really wouldn't mix the "supported"
hardware on production systems.  The largest end users are stuck with what
the ISV approved.  Then add things like security planes, and modern *IX
systems just have to deal with more issues. Users are in trouble even if
their application programs run on an Intel*64 or compatible processor
board, when the user adds hardware subsystems such as different kinds of
interconnects, or when they add other tools that step on each other (for
instance, different tool vendors bring their own MPI) or shared libraries.
 FWIW: I just ran into the shared library issue this week with macOS Tahoe
— some of Apple's binaries and dynamic libraries are compiled as arm64e
[which only Apple can certify — it part of the SIP system], so package
managers must use the traditional arm64; but try to mix certain programs
using exec that have shared libraries and SIP will fail.

From tuhs at tuhs.org  Sat May  9 01:51:00 2026
From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=)
Date: Fri, 08 May 2026 15:51:00 +0000
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
 <20260508142513.GI25310@mcvoy.com>
 <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>
Message-ID: <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>

I've come to realize, only recently, that Apple moving from Intel's x86-64 architecture to their own take on AArch64/ARM64 might help them streamline design, development and production but it's a royal pain in the derriere for many other reasons. Quite a few packages I've tried to install over the last year have turned out to be for Intel x86-64 Macs and nothing later.

Regarding your issue, below, you can disable SIP, or at least, you used to be able to do so.

Have a great rest of your day, everyone. The weekend starts at 5 pm... 



On Friday, May 8th, 2026 at 4:32 PM, Clem Cole via TUHS <tuhs at tuhs.org> wrote, in part:

>  FWIW: I just ran into the shared library issue this week with macOS Tahoe
> — some of Apple's binaries and dynamic libraries are compiled as arm64e
> [which only Apple can certify — it part of the SIP system], so package
> managers must use the traditional arm64; but try to mix certain programs
> using exec that have shared libraries and SIP will fail.
> 

From tuhs at tuhs.org  Sat May  9 03:37:49 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Fri, 08 May 2026 17:37:49 +0000
Subject: [TUHS] Some UNIX/TS Info From John Mashey
Message-ID: <rKWXakJfLvoHkik15uHanqpcDIG19otnVCsbcktLjtAXQEZ3BcCutCRqkQuDsv6ikVXJkj-n2EOAkXMHTO1yJLyGyi6Nkh97oJKfw9y-VM4=@protonmail.com>

Hi folks, I recently contacted John Mashey with some questions about UNIX/TS, he sent along the following information:

> Sure, real quick.
>
> I assume you’ve seen Andrew Tannenbaum’s history, which is pretty good:
>
> https://www.rro.rs/unixarchive-usenet/comp.unix.questions/1988-July/005999.html
>
> although it is ambguous on some dates. My UNIX/TS manual is dated November 1978.
>
> By late 1976, Bell labs management had realized:
>
> a) Almost every project in Bell Labs wsa either using UNIX for development, text-processing or other support activies, OR delivering/planning operations support systems running UNIX.
>
> b) But there was a multiplicity of versions.
>
> So, to start consolidatation,
>
> 3 of us moved from PWB dept to Berk Tague’s UNIX Support Group in early 1977.
>
> Dick Haight Supervisor
>
> Larry Wehr & I, MTS.
>
> Goal was take the not-yet-released but well-along V7, make changes as needed (especially from PWB ruggedizing, accounting, performance, etc),
>
> and get a version suitable for time-sharing, BUT NOT with the CB-UNIX=> USG PG 3 IPC, semaphores, messaging, etc operations support systems stuff.
>
> I.e., we wanted a kernel that PWB dept didn’t have to change to make suitable for the large-user-community, computer-center environments that now existed.
>
> Mid-1979 was PWB/UNIX 2.0, i.e., UNIX/TS kernel+commands, with PWB tools, subsystems like RJE, LEAP, MRCS, etc.
>
> Mid-1980 was System III released outside.
>
> There was no outside System IV, internally, that was when the CB-UNIX features got folded into the mainline, released outside as System V.
>
> https://en.wikipedia.org/wiki/CB_UNIX
>
> Thus:
>
> V7
>
> 1 UNIX/TS
>
> 2 PWB/UNIX 2
>
> 3 System III
>
> 4 System IV (internal only) =<CB-UNIX/USG
>
> 5 System V
>
> I may some day take you up on that offer. I’m slowly going through old documents, trying to clean out house, may find things of interest.
>
> Thanks for kind words. Those were interesting times, and for some more related history, you might have fun with:
>
> The Long Road to 64-bits – double, double, toil & trouble
>
> https://spawn-queue.acm.org/doi/pdf/10.1145/1165754.1165766original in Qqueue, 2006
>
> https://dl.acm.org/doi/10.1145/1435417.1435431then CACM wanted it, 2009
>
> Weirdly, the 2 versions of the above rarely get cited in literature, but together have been downloaded >100K times:
>
> https://dl.acm.org/action/doSearch?AllField=long+road+to+64-bits
>
> One conclusion: ~1975 UNIX was on 16-bit PDP-11s, butC was getting ported to 32-bitters like IBM S?360, XDS Sigma5, etc.
>
> Had we been thinking 15-years ahead, we could have done better with typedefs & programming styles that would have saved much pain later.
>
> More recently:
>
> Interactions, Impacts and Coincidences of the First Golden Age of Computer Architecture
>
> https://techviser.com/wp-content/uploads/2022/06/Mashey.IEEE_.Micro_.2022.pdf
>
>> From:segaloco
>>
>> Sent:Thursday, May 7, 2026 9:42 PM
>>
>> To: John Mashey
>>
>> Subject:RE: UNIX/TS ?
>>
>> Thanks for the reply John! Frankly the thing that interests me the most is what relationship that system had with the Program Generic efforts USG was engaged in before, if the prior system was transformed into TS, if research was resampled, and/or if the earlier work in PWB was incorporated in any of what that system looked like.
>>
>> For some background, I recently helped archive and resurrect a copy of Program Generic Issue 3 from 1977 along with the documentation:
>>
>> https://www.tuhs.org/pipermail/tuhs/2026-April/033604.html
>>
>> This successful effort as well as preserving several UNIX 4.x documents from 1981 has renewed my interest in precisely what sort of rebundling UNIX/TS involved and how it differs from what was around it. It represents a bit of a historical hole which I've been able to flush out a fair deal of documentation surrounding.
>>
>> I'd also like to extend the offer that I am pretty constantly engaged with scanning and archiving lost and obscure UNIX literature, especially BTL/WECo materials. I'd gladly extend my services (and shipping) gratis if you have any notable materials you feel should be preserved.
>>
>> Finally a thank you John for the work you contributed. You and so many others delivered a system that shapes computing to this day and that countless lessons still emerge from.
>>
>> - Matt G.
>>
>> On Thursday, May 7th, 2026 at 21:30, John Mashey wrote:
>>
>>> Sure, that’s me. & I might be able to answer a few questions on UNIX/TS ,although I’d departed the UNIX Support Group in mid-1978 for Whippany, shortly before UNIX/TS released.
>>>
>>>> From:segaloco
>>>>
>>>> Sent:Thursday, May 7, 2026 7:17 PM
>>>>
>>>> To: John Mashey
>>>>
>>>> Subject:UNIX/TS ?
>>>>
>>>> Hello, my name is Matt Gilmore and I hope I am reaching the inbox of John Mashey!
>>>>
>>>> I was wondering if you might be the very same John Mashey of UNIX fame who played a key role in the Programmer's Workbench branch of the software. I'm hoping to get in touch regarding some study I am engaged in documenting USG UNIX developments from the mid 70s. Among other things I've been working to document details concerning the UNIX/TS effort.
>>>>
>>>> - Matt G.

From tuhs at tuhs.org  Sat May  9 03:46:30 2026
From: tuhs at tuhs.org (Larry McVoy via TUHS)
Date: Fri, 8 May 2026 10:46:30 -0700
Subject: [TUHS] Some UNIX/TS Info From John Mashey
In-Reply-To: <rKWXakJfLvoHkik15uHanqpcDIG19otnVCsbcktLjtAXQEZ3BcCutCRqkQuDsv6ikVXJkj-n2EOAkXMHTO1yJLyGyi6Nkh97oJKfw9y-VM4=@protonmail.com>
References: <rKWXakJfLvoHkik15uHanqpcDIG19otnVCsbcktLjtAXQEZ3BcCutCRqkQuDsv6ikVXJkj-n2EOAkXMHTO1yJLyGyi6Nkh97oJKfw9y-VM4=@protonmail.com>
Message-ID: <20260508174630.GL25310@mcvoy.com>

Huh, I just learned that Andrew was part of Masscomp.  Clem, how did that 
come about?

On Fri, May 08, 2026 at 05:37:49PM +0000, segaloco via TUHS wrote:
> Hi folks, I recently contacted John Mashey with some questions about UNIX/TS, he sent along the following information:
> 
> > Sure, real quick.
> >
> > I assume you???ve seen Andrew Tannenbaum???s history, which is pretty good:
> >
> > https://www.rro.rs/unixarchive-usenet/comp.unix.questions/1988-July/005999.html
> >
> > although it is ambguous on some dates. My UNIX/TS manual is dated November 1978.
> >
> > By late 1976, Bell labs management had realized:
> >
> > a) Almost every project in Bell Labs wsa either using UNIX for development, text-processing or other support activies, OR delivering/planning operations support systems running UNIX.
> >
> > b) But there was a multiplicity of versions.
> >
> > So, to start consolidatation,
> >
> > 3 of us moved from PWB dept to Berk Tague???s UNIX Support Group in early 1977.
> >
> > Dick Haight Supervisor
> >
> > Larry Wehr & I, MTS.
> >
> > Goal was take the not-yet-released but well-along V7, make changes as needed (especially from PWB ruggedizing, accounting, performance, etc),
> >
> > and get a version suitable for time-sharing, BUT NOT with the CB-UNIX=> USG PG 3 IPC, semaphores, messaging, etc operations support systems stuff.
> >
> > I.e., we wanted a kernel that PWB dept didn???t have to change to make suitable for the large-user-community, computer-center environments that now existed.
> >
> > Mid-1979 was PWB/UNIX 2.0, i.e., UNIX/TS kernel+commands, with PWB tools, subsystems like RJE, LEAP, MRCS, etc.
> >
> > Mid-1980 was System III released outside.
> >
> > There was no outside System IV, internally, that was when the CB-UNIX features got folded into the mainline, released outside as System V.
> >
> > https://en.wikipedia.org/wiki/CB_UNIX
> >
> > Thus:
> >
> > V7
> >
> > 1 UNIX/TS
> >
> > 2 PWB/UNIX 2
> >
> > 3 System III
> >
> > 4 System IV (internal only) =<CB-UNIX/USG
> >
> > 5 System V
> >
> > I may some day take you up on that offer. I???m slowly going through old documents, trying to clean out house, may find things of interest.
> >
> > Thanks for kind words. Those were interesting times, and for some more related history, you might have fun with:
> >
> > The Long Road to 64-bits ??? double, double, toil & trouble
> >
> > https://spawn-queue.acm.org/doi/pdf/10.1145/1165754.1165766original in Qqueue, 2006
> >
> > https://dl.acm.org/doi/10.1145/1435417.1435431then CACM wanted it, 2009
> >
> > Weirdly, the 2 versions of the above rarely get cited in literature, but together have been downloaded >100K times:
> >
> > https://dl.acm.org/action/doSearch?AllField=long+road+to+64-bits
> >
> > One conclusion: ~1975 UNIX was on 16-bit PDP-11s, butC was getting ported to 32-bitters like IBM S?360, XDS Sigma5, etc.
> >
> > Had we been thinking 15-years ahead, we could have done better with typedefs & programming styles that would have saved much pain later.
> >
> > More recently:
> >
> > Interactions, Impacts and Coincidences of the First Golden Age of Computer Architecture
> >
> > https://techviser.com/wp-content/uploads/2022/06/Mashey.IEEE_.Micro_.2022.pdf
> >
> >> From:segaloco
> >>
> >> Sent:Thursday, May 7, 2026 9:42 PM
> >>
> >> To: John Mashey
> >>
> >> Subject:RE: UNIX/TS ?
> >>
> >> Thanks for the reply John! Frankly the thing that interests me the most is what relationship that system had with the Program Generic efforts USG was engaged in before, if the prior system was transformed into TS, if research was resampled, and/or if the earlier work in PWB was incorporated in any of what that system looked like.
> >>
> >> For some background, I recently helped archive and resurrect a copy of Program Generic Issue 3 from 1977 along with the documentation:
> >>
> >> https://www.tuhs.org/pipermail/tuhs/2026-April/033604.html
> >>
> >> This successful effort as well as preserving several UNIX 4.x documents from 1981 has renewed my interest in precisely what sort of rebundling UNIX/TS involved and how it differs from what was around it. It represents a bit of a historical hole which I've been able to flush out a fair deal of documentation surrounding.
> >>
> >> I'd also like to extend the offer that I am pretty constantly engaged with scanning and archiving lost and obscure UNIX literature, especially BTL/WECo materials. I'd gladly extend my services (and shipping) gratis if you have any notable materials you feel should be preserved.
> >>
> >> Finally a thank you John for the work you contributed. You and so many others delivered a system that shapes computing to this day and that countless lessons still emerge from.
> >>
> >> - Matt G.
> >>
> >> On Thursday, May 7th, 2026 at 21:30, John Mashey wrote:
> >>
> >>> Sure, that???s me. & I might be able to answer a few questions on UNIX/TS ,although I???d departed the UNIX Support Group in mid-1978 for Whippany, shortly before UNIX/TS released.
> >>>
> >>>> From:segaloco
> >>>>
> >>>> Sent:Thursday, May 7, 2026 7:17 PM
> >>>>
> >>>> To: John Mashey
> >>>>
> >>>> Subject:UNIX/TS ?
> >>>>
> >>>> Hello, my name is Matt Gilmore and I hope I am reaching the inbox of John Mashey!
> >>>>
> >>>> I was wondering if you might be the very same John Mashey of UNIX fame who played a key role in the Programmer's Workbench branch of the software. I'm hoping to get in touch regarding some study I am engaged in documenting USG UNIX developments from the mid 70s. Among other things I've been working to document details concerning the UNIX/TS effort.
> >>>>
> >>>> - Matt G.

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

From tuhs at tuhs.org  Sat May  9 03:48:13 2026
From: tuhs at tuhs.org (Adam Thornton via TUHS)
Date: Fri, 8 May 2026 10:48:13 -0700
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
 <20260508142513.GI25310@mcvoy.com>
 <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>
 <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>
Message-ID: <CAP2nic265inKq2VqLVavS3w+nuqc03vjaeiJaDiFR-jKt3aoEw@mail.gmail.com>

The x86_64 emulation in Rosetta 2 is pretty good, although macOS 27 is
going to be the last one that includes it.  However...in general I'd say be
wary of x86_64-only applications.  At least at GCP (I don't know about AWS)
you get slightly more performance per dollar (well...better for integer,
worse for floating point, so it depends on your workload, but mine's mostly
integer) if you go with aarch64 even for Linux.

This isn't the first time an almost-hegemony got dethroned, of course.  We
had, at the beginning of my career (I'm kinda young for this crowd) "all
the world's a VAX".  After that, for a long time, x86 and amd64 came very
close to being the only architecture out there, but then Intel/AMD couldn't
keep up with the need for low-power devices (perhaps because their
instruction set had evolved so incrementally and with so much emphasis on
backwards-compatibility), and ARM basically entirely devoured the mobile
market, and seems to be coming for the server market as energy prices go
up.  Unix has been multiplatform since v6, and both GCC and LLVM support
many,many targets, so there's little excuse for single-architecture
applications.  If whatever you're running is x86-only and it's a Mac app,
then it's probably abandonware.  Which, I mean, fair enough for this crowd,
but also if it was written assuming 2015 hardware specs, it probably runs
just fine under emulation on a modern ARM system.

Generally, it's not that ARM is any faster than x86_64--but it can take
much less energy to give you the same amount of computation.  If you only
have a couple hundred watts of compute at home on things that are mostly
plugged in, you probably don't care, but if you're renting your capacity
from someone else, or trying to run on battery much, it starts to matter a
lot.

Apple has made an interesting choice in this space.  My M1 Macbook Air was
*astonishingly* better than any laptop I'd ever previously owned.  It
wasn't really any faster than what it replaced (an Intel Macbook Pro), but
it had a sixteen-hour battery life while still weighing less (the battery
is of course the majority of the weight of the machine).  The M3 I now
have, on the other hand, is just the boring standard incremental upgrade
over its predecessor.  A little faster, the screen's a slightly better
resolution, but it's not the "I can run for *how* long before I need to
plug into a socket?!?" that the M1 was.

Adam

On Fri, May 8, 2026 at 8:57 AM Cameron Míċeál Tyre via TUHS <tuhs at tuhs.org>
wrote:

> I've come to realize, only recently, that Apple moving from Intel's x86-64
> architecture to their own take on AArch64/ARM64 might help them streamline
> design, development and production but it's a royal pain in the derriere
> for many other reasons. Quite a few packages I've tried to install over the
> last year have turned out to be for Intel x86-64 Macs and nothing later.
>
> Regarding your issue, below, you can disable SIP, or at least, you used to
> be able to do so.
>
> Have a great rest of your day, everyone. The weekend starts at 5 pm...
>
>
>
> On Friday, May 8th, 2026 at 4:32 PM, Clem Cole via TUHS <tuhs at tuhs.org>
> wrote, in part:
>
> >  FWIW: I just ran into the shared library issue this week with macOS
> Tahoe
> > — some of Apple's binaries and dynamic libraries are compiled as arm64e
> > [which only Apple can certify — it part of the SIP system], so package
> > managers must use the traditional arm64; but try to mix certain programs
> > using exec that have shared libraries and SIP will fail.
> >
>

From tuhs at tuhs.org  Sat May  9 04:06:45 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Fri, 08 May 2026 18:06:45 +0000
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <CAP2nic265inKq2VqLVavS3w+nuqc03vjaeiJaDiFR-jKt3aoEw@mail.gmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
 <20260508142513.GI25310@mcvoy.com>
 <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>
 <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>
 <CAP2nic265inKq2VqLVavS3w+nuqc03vjaeiJaDiFR-jKt3aoEw@mail.gmail.com>
Message-ID: <e5kmD-ARsX_DGP7uMP-4JO8pTdjjj8JU9xUOuVBzcAYSeanCLAPiEumvVPuenDIiA9ehAirRrt2tClkvvio6nDOLbgGxE2TXvI5Kvv4XyN4=@protonmail.com>

On Friday, May 8th, 2026 at 10:48, Adam Thornton via TUHS <tuhs at tuhs.org> wrote:

> Generally, it's not that ARM is any faster than x86_64--but it can take
> much less energy to give you the same amount of computation.

With the advent of widespread mobile devices, this was crucial.  Necessity drove ARMs meteoric rise, and now priorities seem to be shifting once again, this time surrounding supply chains and fab redundancy, stuff like that.  My hunch is we're going to start seeing more interest in royalty-free designs like RISC-V and even moreso if there are such designs over in the realm of solid state memory.  No sociopolitical commentary but the TSMC situation is certainly on the mind.  Couple this with the hiring spree companies like Apple and nVidia had in the RISC-V realm several years ago and I suspect we'll start seeing the baby steps towards another tectonic shift possibly in the next decade.

Granted this is now getting quite far afield from the original subject.  To bring it back around, the modern pedagogical V6 port xv6 runs on RISC-V now, so that means there is also hope for bootstrapping other historic UNIX systems (like PG3) on RISC-V.  Given the nature of RISC-V as purely an ISA standard, not an implementation, this implies that UNIX's life has now been extended theoretically indefinitely, RISC-V is supposed to have future proofing baked-into the ISA design, offering an appealing interface to compute that isn't as likely to evaporate in a decade or two.

But that's basicslly what they said about System/360 and VAX was it not?  I guess time will tell if RISC-V really significantly moves the needle in the modern UNIX-like playfield.

- Matt G.

From tuhs at tuhs.org  Sat May  9 04:20:57 2026
From: tuhs at tuhs.org (Warner Losh via TUHS)
Date: Fri, 8 May 2026 12:20:57 -0600
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <e5kmD-ARsX_DGP7uMP-4JO8pTdjjj8JU9xUOuVBzcAYSeanCLAPiEumvVPuenDIiA9ehAirRrt2tClkvvio6nDOLbgGxE2TXvI5Kvv4XyN4=@protonmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
 <20260508142513.GI25310@mcvoy.com>
 <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>
 <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>
 <CAP2nic265inKq2VqLVavS3w+nuqc03vjaeiJaDiFR-jKt3aoEw@mail.gmail.com>
 <e5kmD-ARsX_DGP7uMP-4JO8pTdjjj8JU9xUOuVBzcAYSeanCLAPiEumvVPuenDIiA9ehAirRrt2tClkvvio6nDOLbgGxE2TXvI5Kvv4XyN4=@protonmail.com>
Message-ID: <CANCZdfo=9Y+ja3bG8zv=3+vR9cfirawm+DRPh4fP=Os1RFVL7g@mail.gmail.com>

On Fri, May 8, 2026 at 12:06 PM segaloco via TUHS <tuhs at tuhs.org> wrote:

> On Friday, May 8th, 2026 at 10:48, Adam Thornton via TUHS <tuhs at tuhs.org>
> wrote:
>
> > Generally, it's not that ARM is any faster than x86_64--but it can take
> > much less energy to give you the same amount of computation.
>
> With the advent of widespread mobile devices, this was crucial.  Necessity
> drove ARMs meteoric rise, and now priorities seem to be shifting once
> again, this time surrounding supply chains and fab redundancy, stuff like
> that.  My hunch is we're going to start seeing more interest in
> royalty-free designs like RISC-V and even moreso if there are such designs
> over in the realm of solid state memory.  No sociopolitical commentary but
> the TSMC situation is certainly on the mind.  Couple this with the hiring
> spree companies like Apple and nVidia had in the RISC-V realm several years
> ago and I suspect we'll start seeing the baby steps towards another
> tectonic shift possibly in the next decade.
>
> Granted this is now getting quite far afield from the original subject.
> To bring it back around, the modern pedagogical V6 port xv6 runs on RISC-V
> now, so that means there is also hope for bootstrapping other historic UNIX
> systems (like PG3) on RISC-V.


xv6 was written for 32-bit i386, so porting wasn't so bad.
The Unixes of this era (PG3 roughly V6) don't yet have the portability
fixes that even the 7th Edition has, so there's a lot of porting to be
done. None of the sizes of things are abstracted, so there's a lot of +2
baked into the code since it knows that's how big a pointer is..
Sure would be a cool project, though. The Miller papers on the Wollongong
Interdata port have many of the details...

Warner


> Given the nature of RISC-V as purely an ISA standard, not an
> implementation, this implies that UNIX's life has now been extended
> theoretically indefinitely, RISC-V is supposed to have future proofing
> baked-into the ISA design, offering an appealing interface to compute that
> isn't as likely to evaporate in a decade or two.
>
> But that's basicslly what they said about System/360 and VAX was it not?
> I guess time will tell if RISC-V really significantly moves the needle in
> the modern UNIX-like playfield.
>
> - Matt G.
>

From tuhs at tuhs.org  Sat May  9 04:28:01 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Fri, 8 May 2026 14:28:01 -0400
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
 <20260508142513.GI25310@mcvoy.com>
 <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>
 <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>
Message-ID: <CAC20D2N_q2HPf_T-a_gdrAtHGmTFgR7rGUaweYgvP3L9eNRkPQ@mail.gmail.com>

On Fri, May 8, 2026 at 11:51 AM Cameron Míċeál Tyre via TUHS <tuhs at tuhs.org>
wrote:

> I've come to realize, only recently, that Apple moving from Intel's x86-64
> architecture to their own take on AArch64/ARM64 might help them streamline
> design, development and production but it's a royal pain in the derriere
> for many other reasons. Quite a few packages I've tried to install over the
> last year have turned out to be for Intel x86-64 Macs and nothing later.
>
> Regarding your issue, below, you can disable SIP, or at least, you used to
> be able to do so.
>
Yes, but it does not change the arm64e / arm64 binary issue on macOS; a
binary stored in a macho file marked as arm64e includes Pointer
Authentication Codes (PAC).

PAC is an Apple security feature designed to prevent memory corruption and
code-injection attacks.  The two binary formats differ in instruction set
features and how the OS handles them:

   - Security (PAC): arm64e utilizes ARMv8.3-A instructions to
   cryptographically sign and verify pointers (like return addresses and
   function pointers) before use. If a pointer is tampered with by malware,
   the authentication fails, and the program crashes safely instead of
   executing malicious code. Standard arm64 binaries do not use these
   instructions.
   - ABI Stability: The arm64e Application Binary Interface (ABI) is
   considered unstable and "private" by Apple. Apple uses it for all its
   own system software—such as the kernel and system libraries—because they
   can recompile the entire OS if the ABI changes.
   - Third-Party Support: Most third-party apps are distributed as arm64.
   Apple generally restricts the distribution of arm64e binaries in the App
   Store because the changing ABI would cause them to break on future macOS
   updates.
   - Binary Execution:
      - arm64 binaries run on all Apple Silicon Macs.
      - arm64e binaries only run on processors that support PAC (A12 chips
      or M1 and newer) and usually require special developer "preview" flags to
      run if they aren't signed by Apple.
   - Interoperability: An arm64 executable can call arm64e libraries, but
   an arm64e executable cannot call standard arm64 libraries for security
   reasons, as doing so would bypass the pointer protections.

This last point is what bites brew in the backside, with dynamic libraries
[which is how I ran into the problem earlier this week].

From tuhs at tuhs.org  Sat May  9 04:47:08 2026
From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=)
Date: Fri, 08 May 2026 18:47:08 +0000
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <CAC20D2N_q2HPf_T-a_gdrAtHGmTFgR7rGUaweYgvP3L9eNRkPQ@mail.gmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
 <20260508142513.GI25310@mcvoy.com>
 <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>
 <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>
 <CAC20D2N_q2HPf_T-a_gdrAtHGmTFgR7rGUaweYgvP3L9eNRkPQ@mail.gmail.com>
Message-ID: <mlQ3ByWkO9sEtDQksKb6Kxn7yt8gMuEQM5xnCIBMP4mEjEw-g4Fu27kpEfJaLXRFar5R_uZit3CQMzQyS0bFbwfYvrHbjiqyMy-biQBjca4=@protonmail.ch>

Ah, gotcha. Another thing I learned today and always glad to, thank you.


On Friday, May 8th, 2026 at 7:28 PM, Clem Cole <clemc at ccc.com> wrote, in part:

> 
> -   Interoperability: An arm64 executable can call arm64e libraries, but an arm64e executable cannot call standard arm64 libraries for security reasons, as doing so would bypass the pointer protections.
> 
> This last point is what bites brew in the backside, with dynamic libraries [which is how I ran into the problem earlier this week].

From tuhs at tuhs.org  Sat May  9 06:23:05 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Fri, 8 May 2026 16:23:05 -0400
Subject: [TUHS] Looking for a copy of Dennis's original standard I/O library
 paper from 1977
Message-ID: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>

All the recent discussion about the original of the B Programming Language,
PG UNIX, UNIX/TS, et al, got me thinking of something else that so far has
been lost to time.  In 1977, Dennis published a Bell Laboratories internal
memorandum entitled: "*A New Input-Output **Package*," which described libS.
a for the then-current Sixth Edition.  This is also the time frame of USG's
work on Program Generic UNIX and what would be called UNIX/TS 1.0. The contents
of this paper were rewritten to become Chapter 7 of K&R1 (including on page
144, discussion of -lS needed to be included at compile/link time).

I would like to add a copy of the original paper to the TUHS archives, but
I have been unable to find one so far.  The one place I thought I might
have one, I recently examined and was disappointed to find I had not kept that
from my CMU days.

My memory (which could be wrong here) was that it was included in the
"Typesetter C" release, which was a compiler release for Sixth Edition
sites that had obtained a license for a late 1970s version of a C source'd
troff.  The C compiler was an updated version of DMR's compiler with
support for unsigned and union data types, typedef and bit-fields; as well
as the new Standard I/O library (*a.k.a.*, libS.a) - as some of these had
made their way into the "croff" source.  That said, looking at the croff
sources in PWB 1.0 shows that version doesn't use any of those features,
and we know Joe died in 1977 — and I just don't remember what was in the
distribution.

As i said, my memory is hazy on all this.  What I do remember is that we
had a flavor of Joe's troff for the C/A/T at Tektronix in the late 1970s,
and we were using a copy of vcat(1) that I got from Tom Ferrin at UCSF to
"typeset" to a Versatec plotter.

I will also note that Brian certainly used the new C language features, but
he did not start on ditroff until 1979, published the paper on it in 1982,
and in 1983 it was part of DWB.

So .. if anyone can find a copy of the document, please let me know.

Thanks,
Clem

From tuhs at tuhs.org  Sat May  9 06:43:48 2026
From: tuhs at tuhs.org (Thalia Archibald via TUHS)
Date: Fri, 08 May 2026 20:43:48 +0000
Subject: [TUHS] Looking for a copy of Dennis's original standard I/O
 library paper from 1977
In-Reply-To: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
References: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
Message-ID: <6E9F13BE-CC02-4F0E-86FE-EA8DC1898A14@archibald.dev>

On May 8, 2026, at 13:23, Clem Cole wrote:
> All the recent discussion about the original of the B Programming Language,
> PG UNIX, UNIX/TS, et al, got me thinking of something else that so far has
> been lost to time.  In 1977, Dennis published a Bell Laboratories internal
> memorandum entitled: "*A New Input-Output **Package*," which described libS.
> a for the then-current Sixth Edition.  This is also the time frame of USG's
> work on Program Generic UNIX and what would be called UNIX/TS 1.0. The contents
> of this paper were rewritten to become Chapter 7 of K&R1 (including on page
> 144, discussion of -lS needed to be included at compile/link time).
> 
> I would like to add a copy of the original paper to the TUHS archives, but
> I have been unable to find one so far.  The one place I thought I might
> have one, I recently examined and was disappointed to find I had not kept that
> from my CMU days.

This reminds me of Mike Leak’s portable C library, the immediate ancestor of
stdio. There appear to be at least three revisions of the paper:

- 1973: cited by https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf
- 1975-05-16: https://archive.org/details/ThePortableCLibrary_May75
- 1975-06-27: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/iolib/iolib

The 1973 version is not archived, but Mike could be emailed.

Discussion, including an answer of yours:
    https://retrocomputing.stackexchange.com/questions/25471/where-is-mike-lesks-circa-1973-portable-i-o-package-for-c

Thalia

From tuhs at tuhs.org  Sat May  9 07:27:48 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Fri, 8 May 2026 17:27:48 -0400
Subject: [TUHS] Looking for a copy of Dennis's original standard I/O
 library paper from 1977
In-Reply-To: <6E9F13BE-CC02-4F0E-86FE-EA8DC1898A14@archibald.dev>
References: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
 <6E9F13BE-CC02-4F0E-86FE-EA8DC1898A14@archibald.dev>
Message-ID: <CAC20D2PZRRUoqqty0-ueJV7sd2MjRaee216DoVknORt092Nkrw@mail.gmail.com>

below

On Fri, May 8, 2026 at 4:43 PM Thalia Archibald <thalia at archibald.dev>
wrote:

> On May 8, 2026, at 13:23, Clem Cole wrote:
> > All the recent discussion about the original of the B Programming
> Language,
> > PG UNIX, UNIX/TS, et al, got me thinking of something else that so far
> has
> > been lost to time.  In 1977, Dennis published a Bell Laboratories
> internal
> > memorandum entitled: "*A New Input-Output **Package*," which described
> libS.
> > a for the then-current Sixth Edition.  This is also the time frame of
> USG's
> > work on Program Generic UNIX and what would be called UNIX/TS 1.0. The
> contents
> > of this paper were rewritten to become Chapter 7 of K&R1 (including on
> page
> > 144, discussion of -lS needed to be included at compile/link time).
> >
> > I would like to add a copy of the original paper to the TUHS archives,
> but
> > I have been unable to find one so far.  The one place I thought I might
> > have one, I recently examined and was disappointed to find I had not
> kept that
> > from my CMU days.
>
> This reminds me of Mike Leak’s portable C library, the immediate ancestor
> of
> stdio. There appear to be at least three revisions of the paper:
>
> - 1973: cited by
> https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf

I don't think I ever saw this version.

>
> - 1975-05-16: https://archive.org/details/ThePortableCLibrary_May75

Thanks,  I had seen this before and it is the most complete. It talks about
things that he did not discuss in the version packaged with Sixth Edition.
Besides making sure its in the TUHS Document's archives, we need check to
ensure that it does indeed match the code; as well as trying to OCR it and
see if we can recreate a cleaner version like I did with some of the B
stuff from Dennis.

>
> - 1975-06-27:
> https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/iolib/iolib

While the date is a month later, I suspect that is an artificat of the
packaging of things to create the release and Dennis had grabbed an earlier
verion.

>
>
> The 1973 version is not archived, but Mike could be emailed.
>
Certainly, if only to see what changed.  It would be best if we had both
the earlier version and the code, but I suspect we have lost both to time.
I'll try close the loop with Mike.

>
> Discussion, including an answer of yours:
>
> https://retrocomputing.stackexchange.com/questions/25471/where-is-mike-lesks-circa-1973-portable-i-o-package-for-c

Yes, and I pointed to the V6  version.   One of my longer term desires is
in the TUHS archives to add a PDF and HTML directories for each release
that has the doc files and man files turned into ODF abnd HTML for better
viewing.   That said Branden Robinson has been super when I have run into
issues when I have tried to make modern rendering with groff of many of
these older docs.

>
>
> Thalia
>

From tuhs at tuhs.org  Sat May  9 08:41:18 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Fri, 08 May 2026 22:41:18 +0000
Subject: [TUHS] Looking for a copy of Dennis's original standard I/O
 library paper from 1977
In-Reply-To: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
References: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
Message-ID: <eMjLjn53hQNt7u8BXyaOBOjZmOuWVvVen8YrCsx_WuawrUIq0G8Lim30sdyzUd3NCw4_-oxldVWnFkwaTtnJ2LvVDZeTCpHSwQYmgmGLWDE=@protonmail.com>

On Friday, May 8th, 2026 at 13:23, Clem Cole via TUHS <tuhs at tuhs.org> wrote:

> All the recent discussion about the original of the B Programming Language,
> PG UNIX, UNIX/TS, et al, got me thinking of something else that so far has
> been lost to time.  In 1977, Dennis published a Bell Laboratories internal
> memorandum entitled: "*A New Input-Output **Package*," which described libS.
> a for the then-current Sixth Edition.

It looks like someone has digitized it as an HTML page here:

http://roguelife.org/~fujita/COOKIES/HISTORY/V6/newgear.html

Looks to be a Japanese UNIX history webpage:

http://roguelife.org/~fujita/COOKIES/HISTORY/

I haven't explored the rest of their stuff, busy with a
work thing right now, but that might bear some further leads.
Note the http: if anyone is paranoid about that sort of thing.
Not like you're sending credentials but as someone who is on
https-only and has to approve all my http connections I got my
expected popup, so fyi.

- Matt G.

From tuhs at tuhs.org  Sat May  9 09:34:27 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Fri, 8 May 2026 19:34:27 -0400
Subject: [TUHS] Looking for a copy of Dennis's original standard I/O
 library paper from 1977
In-Reply-To: <eMjLjn53hQNt7u8BXyaOBOjZmOuWVvVen8YrCsx_WuawrUIq0G8Lim30sdyzUd3NCw4_-oxldVWnFkwaTtnJ2LvVDZeTCpHSwQYmgmGLWDE=@protonmail.com>
References: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
 <eMjLjn53hQNt7u8BXyaOBOjZmOuWVvVen8YrCsx_WuawrUIq0G8Lim30sdyzUd3NCw4_-oxldVWnFkwaTtnJ2LvVDZeTCpHSwQYmgmGLWDE=@protonmail.com>
Message-ID: <CAC20D2NhW=D9nOLZ2VbzZ0Tte_gj_qs5m-x42m_Myu=+9SME8g@mail.gmail.com>

Matt,

 Thank you.   With Nelson's help we did find a copy inside of the PWB 1.0
docs, though it's of very poor quality.
https://bitsavers.org/pdf/att/unix/PWB_UNIX/Documents_for_the_PWB_UNIX_Time-Sharing_System_Edition_1.0_197710.pdf
[pgs 169-174]

By looking at Nelson's wonderful Unix Bibliography database, it looks like
Dennis might have published it as TM1159, on 6-May-1977

As for this HTML file, unfortunately, it is both incomplete (missing
several sections, including details on printf) and has a few entries that
the PWB version lacks for a couple of string routines.

On Fri, May 8, 2026 at 6:41 PM segaloco via TUHS <tuhs at tuhs.org> wrote:

> On Friday, May 8th, 2026 at 13:23, Clem Cole via TUHS <tuhs at tuhs.org>
> wrote:
>
> > All the recent discussion about the original of the B Programming
> Language,
> > PG UNIX, UNIX/TS, et al, got me thinking of something else that so far
> has
> > been lost to time.  In 1977, Dennis published a Bell Laboratories
> internal
> > memorandum entitled: "*A New Input-Output **Package*," which described
> libS.
> > a for the then-current Sixth Edition.
>
> It looks like someone has digitized it as an HTML page here:
>
> http://roguelife.org/~fujita/COOKIES/HISTORY/V6/newgear.html
>
> Looks to be a Japanese UNIX history webpage:
>
> http://roguelife.org/~fujita/COOKIES/HISTORY/
>
> I haven't explored the rest of their stuff, busy with a
> work thing right now, but that might bear some further leads.
> Note the http: if anyone is paranoid about that sort of thing.
> Not like you're sending credentials but as someone who is on
> https-only and has to approve all my http connections I got my
> expected popup, so fyi.
>
> - Matt G.
>

From tuhs at tuhs.org  Sat May  9 10:22:54 2026
From: tuhs at tuhs.org (Anthony Martin via TUHS)
Date: Fri, 8 May 2026 17:22:54 -0700
Subject: [TUHS] Looking for a copy of Dennis's original standard I/O
 library paper from 1977
In-Reply-To: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
References: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
Message-ID: <af5-XomCQS-3t8AX@alice>

Is this the version you're looking for?

https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/libc/stdio/ios.r

It looks like it uses pretty standard ms(6) macros.
The Plan 9 version of troff(1) handles it well.

Cheers,
  Anthony

From tuhs at tuhs.org  Sat May  9 11:07:30 2026
From: tuhs at tuhs.org (Jonathan Gray via TUHS)
Date: Sat, 9 May 2026 11:07:30 +1000
Subject: [TUHS] Some UNIX/TS Info From John Mashey
In-Reply-To: <20260508174630.GL25310@mcvoy.com>
References: <rKWXakJfLvoHkik15uHanqpcDIG19otnVCsbcktLjtAXQEZ3BcCutCRqkQuDsv6ikVXJkj-n2EOAkXMHTO1yJLyGyi6Nkh97oJKfw9y-VM4=@protonmail.com>
 <20260508174630.GL25310@mcvoy.com>
Message-ID: <af6I0tQo5Al3cEts@largo.jsg.id.au>

On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote:
> Huh, I just learned that Andrew was part of Masscomp.  Clem, how did that 
> come about?

The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not
the Andrew Tanenbaum (ast) associated with MINIX.

From tuhs at tuhs.org  Sat May  9 11:24:35 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Fri, 8 May 2026 21:24:35 -0400
Subject: [TUHS] Looking for a copy of Dennis's original standard I/O
 library paper from 1977
In-Reply-To: <af5-XomCQS-3t8AX@alice>
References: <CAC20D2PZYx9HmshMo-LpN_FH2jR+gtBoQ6OErEBJm==VTQLWPg@mail.gmail.com>
 <af5-XomCQS-3t8AX@alice>
Message-ID: <CAC20D2PkiPtphz7kJs+BkRaK9g7aoLteDByszUCJmDyJYq=bCg@mail.gmail.com>

Yes, it is!!  Thank you.  And now I see we have a number of copies
scattered in the archives.   It's in the s4 directory of the PWB1.0
sources, on the BBN tcp tape, and in 2.9, 2.11, and 4.3BSD as part of the
ctour directories, and I just found another copy in the uu.net archives.

On Fri, May 8, 2026 at 8:23 PM Anthony Martin <ality at pbrane.org> wrote:

> Is this the version you're looking for?
>
> https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/libc/stdio/ios.r
>
> It looks like it uses pretty standard ms(6) macros.
> The Plan 9 version of troff(1) handles it well.
>
> Cheers,
>   Anthony
>

From tuhs at tuhs.org  Sat May  9 11:30:04 2026
From: tuhs at tuhs.org (Larry McVoy via TUHS)
Date: Fri, 8 May 2026 18:30:04 -0700
Subject: [TUHS] Some UNIX/TS Info From John Mashey
In-Reply-To: <af6I0tQo5Al3cEts@largo.jsg.id.au>
References: <rKWXakJfLvoHkik15uHanqpcDIG19otnVCsbcktLjtAXQEZ3BcCutCRqkQuDsv6ikVXJkj-n2EOAkXMHTO1yJLyGyi6Nkh97oJKfw9y-VM4=@protonmail.com>
 <20260508174630.GL25310@mcvoy.com>
 <af6I0tQo5Al3cEts@largo.jsg.id.au>
Message-ID: <20260509013004.GN25310@mcvoy.com>

On Sat, May 09, 2026 at 11:07:30AM +1000, Jonathan Gray wrote:
> On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote:
> > Huh, I just learned that Andrew was part of Masscomp.  Clem, how did that 
> > come about?
> 
> The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not
> the Andrew Tanenbaum (ast) associated with MINIX.

But it was the Masscomp guy who did the history writeup?  I could see that
with Clem at Masscomp, Clem knows the history.

Thanks for the clarification Jonathan, appreciate it.

In the information you didn't ask for department, I'm half Dutch,
have lived there, learned the language, some, and I interviewed with
ast to go to grad school there (I think, it was a long time ago, when I
went there is not clear but I did interview with him).  I really liked
the Minix idea, it wasn't as good as QNX but it was mostly (I think)
just him.  It's a significant chunk of work.  I decided to pass because
the building he was in was gray, the furniture was gray, the weather
was gray.  That's trite but where he was working just didn't suck me in.
While I don't regret that choice, I think working with him could have
been fun.

--lm

From tuhs at tuhs.org  Sat May  9 12:50:56 2026
From: tuhs at tuhs.org (Dan Cross via TUHS)
Date: Fri, 8 May 2026 22:50:56 -0400
Subject: [TUHS] PG3 or Gen3.0?
In-Reply-To: <e5kmD-ARsX_DGP7uMP-4JO8pTdjjj8JU9xUOuVBzcAYSeanCLAPiEumvVPuenDIiA9ehAirRrt2tClkvvio6nDOLbgGxE2TXvI5Kvv4XyN4=@protonmail.com>
References: <14F881FA-BC9D-4221-B964-0693B745A485@archibald.dev>
 <IsGOVoQFSj-LnwviXN5WpHVZRG6X0DEXr5HHmS84Krit8tPr0g21T8T6DfPrF6MDfhVWf60OEdQRlCwAy3hTUjy19YbBAhl5CpvpQkBQdnk=@protonmail.com>
 <3ShBuGJ9zanezkFrydF-eYc-RTLkkjD-Gr11kT1nHPmu5Vz2xTrblEVmB30nI3HBqcyNog1sv0iAZX2kzjXJ1HyAfZq2hC0NKmhHtcH4Ong=@protonmail.com>
 <20260508001138.GE25310@mcvoy.com>
 <CAC20D2M-1nUyfyAzRtaAu6AtfPtCGCWVbTjMtPa4qR6eDnQYwg@mail.gmail.com>
 <20260508142513.GI25310@mcvoy.com>
 <CAC20D2NxCjb=AX0b-LFWqmbHG3dupD40f_1--3AMjLjLoYG7tw@mail.gmail.com>
 <ntgof5baCkiHpD2Fw6YI4nSsGaaPlnsGXH7ltqjIx1IOJiXbqPnB4wFsoPsIMFTpBsS3nRqHgboOuWDZp5hY0vFSkGdDdlzpvCdn5zRLSfQ=@protonmail.ch>
 <CAP2nic265inKq2VqLVavS3w+nuqc03vjaeiJaDiFR-jKt3aoEw@mail.gmail.com>
 <e5kmD-ARsX_DGP7uMP-4JO8pTdjjj8JU9xUOuVBzcAYSeanCLAPiEumvVPuenDIiA9ehAirRrt2tClkvvio6nDOLbgGxE2TXvI5Kvv4XyN4=@protonmail.com>
Message-ID: <CAEoi9W5ZCiSnG4ZuTi0TtMQGuXC73GGpKeFBwsnJkTmzZ1pE5A@mail.gmail.com>

On Fri, May 8, 2026 at 2:17 PM segaloco via TUHS <tuhs at tuhs.org> wrote:
> Granted this is now getting quite far afield from the original subject.  To bring it back around, the modern pedagogical V6 port xv6 runs on RISC-V now, so that means there is also hope for bootstrapping other historic UNIX systems (like PG3) on RISC-V.

Yeah, as Warner pointed out, this isn't quite accurate.

xv6 isn't a port in any meaningful way, and in particular it shares no
code with 6th Ed. Rather, it is an independent reimplementation along
similar design lines. Even under that very loose constraint, however,
much is different.

Some things were added to be there from the start: xv6 protects kernel
data structures with fine-grained locks, and has supported SMP
machines from inception.  Additionally, virtual memory segments are
constructed on top of a page-based virtual address space.

Some were removed: xv6 doesn't really support a notion of "users" or
terminal devices, file permissions really exist (partly as a
consequence of not having users), and a number of system calls were
deliberately not added.

These differences are not gratuitous, but rather pragmatic: it's a
pedagogical system, so the selection is primarily based on educational
relevance. Some things (a few system calls, etc) are left as exercises
for students.

        - Dan C.

From tuhs at tuhs.org  Sat May  9 15:54:26 2026
From: tuhs at tuhs.org (Andy Kosela via TUHS)
Date: Sat, 9 May 2026 07:54:26 +0200
Subject: [TUHS] Some UNIX/TS Info From John Mashey
In-Reply-To: <20260509013004.GN25310@mcvoy.com>
References: <rKWXakJfLvoHkik15uHanqpcDIG19otnVCsbcktLjtAXQEZ3BcCutCRqkQuDsv6ikVXJkj-n2EOAkXMHTO1yJLyGyi6Nkh97oJKfw9y-VM4=@protonmail.com>
 <20260508174630.GL25310@mcvoy.com> <af6I0tQo5Al3cEts@largo.jsg.id.au>
 <20260509013004.GN25310@mcvoy.com>
Message-ID: <CALMnNGgKejrCB3u6R-nP_1fkq6MWgNFekKWmVue0uEe_YtRYzQ@mail.gmail.com>

On Sat, May 9, 2026 at 3:30 AM Larry McVoy via TUHS <tuhs at tuhs.org> wrote:

> On Sat, May 09, 2026 at 11:07:30AM +1000, Jonathan Gray wrote:
> > On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote:
> > > Huh, I just learned that Andrew was part of Masscomp.  Clem, how did
> that
> > > come about?
> >
> > The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not
> > the Andrew Tanenbaum (ast) associated with MINIX.
>
> But it was the Masscomp guy who did the history writeup?  I could see that
> with Clem at Masscomp, Clem knows the history.
>
> Thanks for the clarification Jonathan, appreciate it.
>
> In the information you didn't ask for department, I'm half Dutch,
> have lived there, learned the language, some, and I interviewed with
> ast to go to grad school there (I think, it was a long time ago, when I
> went there is not clear but I did interview with him).  I really liked
> the Minix idea, it wasn't as good as QNX but it was mostly (I think)
> just him.  It's a significant chunk of work.  I decided to pass because
> the building he was in was gray, the furniture was gray, the weather
> was gray.  That's trite but where he was working just didn't suck me in.
> While I don't regret that choice, I think working with him could have
> been fun.


While MINIX 1 and 2 were mostly AST’s work and aimed at education, MINIX 3
was a different beast. It was intended to be production-grade and developed
as a collaborative effort. I know this because I contributed some code to
it. It also leveraged the NetBSD userland.

That included:

- NetBSD libc
- NetBSD build infrastructure
- many NetBSD userland utilities: ls, cp, sh, etc.
- NetBSD bootloader components
- pkgsrc package system

In practice, later MINIX 3 felt closer to a small NetBSD-like system
running on top of the MINIX microkernel than to the older, fully
self-contained MINIX 1/2 systems. It was really nice and I am still amazed
why it did not become more popular.

--Andy

From tuhs at tuhs.org  Sat May  9 22:31:03 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Sat, 9 May 2026 08:31:03 -0400
Subject: [TUHS] Some UNIX/TS Info From John Mashey
In-Reply-To: <CALMnNGgKejrCB3u6R-nP_1fkq6MWgNFekKWmVue0uEe_YtRYzQ@mail.gmail.com>
References: <rKWXakJfLvoHkik15uHanqpcDIG19otnVCsbcktLjtAXQEZ3BcCutCRqkQuDsv6ikVXJkj-n2EOAkXMHTO1yJLyGyi6Nkh97oJKfw9y-VM4=@protonmail.com>
 <20260508174630.GL25310@mcvoy.com> <af6I0tQo5Al3cEts@largo.jsg.id.au>
 <20260509013004.GN25310@mcvoy.com>
 <CALMnNGgKejrCB3u6R-nP_1fkq6MWgNFekKWmVue0uEe_YtRYzQ@mail.gmail.com>
Message-ID: <CAC20D2P86UeMPEmfSvjskH0pf1nyW_U3cYh7-1Bn7OJ+RuWaJg@mail.gmail.com>

Yes, he was an early Masscomp hacker. How did that happen?  Easy, trb was a
friend of mine from a few years previously. I had joined Masscomp as the
second Unix hacker to help Tom with the O very early on. But shortly there
after we started expanding as there was a lot to do, and I introduced trb
to our VP of Eng (Lorin Gale) and Lorin hired him. IIRC: He worked
extensively on the command system, for maybe two or three years.

As I recall he was living closer to Boston proper and had a social life
centered around Cambridge.  While Masscomp was out on 495
(Littleton/Westford), so he had a bit if a haul. Eventually he took a job
closer Cambridge. At some point he landed in the Boston office of
Interactive Systems Corp, which is when he wrote that note, but I don’t
remember if he had a stop somewhere else before that. I’ll have to ask him.


Clem


Sent from a handheld expect more typos than usual

On Sat, May 9, 2026 at 1:54 AM Andy Kosela via TUHS <tuhs at tuhs.org> wrote:

> On Sat, May 9, 2026 at 3:30 AM Larry McVoy via TUHS <tuhs at tuhs.org> wrote:
>
> > On Sat, May 09, 2026 at 11:07:30AM +1000, Jonathan Gray wrote:
> > > On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote:
> > > > Huh, I just learned that Andrew was part of Masscomp.  Clem, how did
> > that
> > > > come about?
> > >
> > > The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not
> > > the Andrew Tanenbaum (ast) associated with MINIX.
> >
> > But it was the Masscomp guy who did the history writeup?  I could see
> that
> > with Clem at Masscomp, Clem knows the history.
> >
> > Thanks for the clarification Jonathan, appreciate it.
> >
> > In the information you didn't ask for department, I'm half Dutch,
> > have lived there, learned the language, some, and I interviewed with
> > ast to go to grad school there (I think, it was a long time ago, when I
> > went there is not clear but I did interview with him).  I really liked
> > the Minix idea, it wasn't as good as QNX but it was mostly (I think)
> > just him.  It's a significant chunk of work.  I decided to pass because
> > the building he was in was gray, the furniture was gray, the weather
> > was gray.  That's trite but where he was working just didn't suck me in.
> > While I don't regret that choice, I think working with him could have
> > been fun.
>
>
> While MINIX 1 and 2 were mostly AST’s work and aimed at education, MINIX 3
> was a different beast. It was intended to be production-grade and developed
> as a collaborative effort. I know this because I contributed some code to
> it. It also leveraged the NetBSD userland.
>
> That included:
>
> - NetBSD libc
> - NetBSD build infrastructure
> - many NetBSD userland utilities: ls, cp, sh, etc.
> - NetBSD bootloader components
> - pkgsrc package system
>
> In practice, later MINIX 3 felt closer to a small NetBSD-like system
> running on top of the MINIX microkernel than to the older, fully
> self-contained MINIX 1/2 systems. It was really nice and I am still amazed
> why it did not become more popular.
>
> --Andy
>

From tuhs at tuhs.org  Sat May  9 22:39:19 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Sat, 9 May 2026 08:39:19 -0400
Subject: [TUHS] Some UNIX/TS Info From John Mashey
In-Reply-To: <CAC20D2P86UeMPEmfSvjskH0pf1nyW_U3cYh7-1Bn7OJ+RuWaJg@mail.gmail.com>
References: <rKWXakJfLvoHkik15uHanqpcDIG19otnVCsbcktLjtAXQEZ3BcCutCRqkQuDsv6ikVXJkj-n2EOAkXMHTO1yJLyGyi6Nkh97oJKfw9y-VM4=@protonmail.com>
 <20260508174630.GL25310@mcvoy.com> <af6I0tQo5Al3cEts@largo.jsg.id.au>
 <20260509013004.GN25310@mcvoy.com>
 <CALMnNGgKejrCB3u6R-nP_1fkq6MWgNFekKWmVue0uEe_YtRYzQ@mail.gmail.com>
 <CAC20D2P86UeMPEmfSvjskH0pf1nyW_U3cYh7-1Bn7OJ+RuWaJg@mail.gmail.com>
Message-ID: <CAC20D2Micqm9W9aktG8CzjZt7M5c8KjjWfhomR9xy4=nmOmtzQ@mail.gmail.com>

BTW: for people newish to the Unix community, as noted there are two people
in our community named Andy Tannenbaum. They are both wonderful people, and
have enjoyed knowing them both. And for those of us that have known them,
they are sometimes referred to as “landscape” and “portrait” - I’ll leave
it to the reader to find pictures of each and to figure out which us which.
😉


Sent from a handheld expect more typos than usual

On Sat, May 9, 2026 at 8:31 AM Clem Cole <clemc at ccc.com> wrote:

> Yes, he was an early Masscomp hacker. How did that happen?  Easy, trb was
> a friend of mine from a few years previously. I had joined Masscomp as the
> second Unix hacker to help Tom with the O very early on. But shortly
> there after we started expanding as there was a lot to do, and I
> introduced trb to our VP of Eng (Lorin Gale) and Lorin hired him. IIRC: He
> worked extensively on the command system, for maybe two or three years.
>
> As I recall he was living closer to Boston proper and had a social life
> centered around Cambridge.  While Masscomp was out on 495
> (Littleton/Westford), so he had a bit if a haul. Eventually he took a job
> closer Cambridge. At some point he landed in the Boston office of
> Interactive Systems Corp, which is when he wrote that note, but I don’t
> remember if he had a stop somewhere else before that. I’ll have to ask him.
>
>
> Clem
>
>
> Sent from a handheld expect more typos than usual
>
> On Sat, May 9, 2026 at 1:54 AM Andy Kosela via TUHS <tuhs at tuhs.org> wrote:
>
>> On Sat, May 9, 2026 at 3:30 AM Larry McVoy via TUHS <tuhs at tuhs.org>
>> wrote:
>>
>> > On Sat, May 09, 2026 at 11:07:30AM +1000, Jonathan Gray wrote:
>> > > On Fri, May 08, 2026 at 10:46:30AM -0700, Larry McVoy via TUHS wrote:
>> > > > Huh, I just learned that Andrew was part of Masscomp.  Clem, how did
>> > that
>> > > > come about?
>> > >
>> > > The Andrew Tannenbaum (trb) who worked at Masscomp and ISC is not
>> > > the Andrew Tanenbaum (ast) associated with MINIX.
>> >
>> > But it was the Masscomp guy who did the history writeup?  I could see
>> that
>> > with Clem at Masscomp, Clem knows the history.
>> >
>> > Thanks for the clarification Jonathan, appreciate it.
>> >
>> > In the information you didn't ask for department, I'm half Dutch,
>> > have lived there, learned the language, some, and I interviewed with
>> > ast to go to grad school there (I think, it was a long time ago, when I
>> > went there is not clear but I did interview with him).  I really liked
>> > the Minix idea, it wasn't as good as QNX but it was mostly (I think)
>> > just him.  It's a significant chunk of work.  I decided to pass because
>> > the building he was in was gray, the furniture was gray, the weather
>> > was gray.  That's trite but where he was working just didn't suck me in.
>> > While I don't regret that choice, I think working with him could have
>> > been fun.
>>
>>
>> While MINIX 1 and 2 were mostly AST’s work and aimed at education, MINIX 3
>> was a different beast. It was intended to be production-grade and
>> developed
>> as a collaborative effort. I know this because I contributed some code to
>> it. It also leveraged the NetBSD userland.
>>
>> That included:
>>
>> - NetBSD libc
>> - NetBSD build infrastructure
>> - many NetBSD userland utilities: ls, cp, sh, etc.
>> - NetBSD bootloader components
>> - pkgsrc package system
>>
>> In practice, later MINIX 3 felt closer to a small NetBSD-like system
>> running on top of the MINIX microkernel than to the older, fully
>> self-contained MINIX 1/2 systems. It was really nice and I am still amazed
>> why it did not become more popular.
>>
>> --Andy
>>
>

From tuhs at tuhs.org  Sun May 10 01:40:09 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Sat, 09 May 2026 15:40:09 +0000
Subject: [TUHS] PDP-11/20 On eBay
Message-ID: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>

Its your "hey this might interest TUHS members and I can't justify the buy" occasional auction mention:

https://www.ebay.com/itm/327147586264

After the link is an auction for a PDP-11/20 with a KE11-A Extended Arithmetic Element.  I don't off the top of my head know if this is enough to be the core of a V1/V2 system, but figured I'd mention it in case any intrepid list members are trying to roll a real V1/V2 setup.  Happy hunting!

- Matt G.

From tuhs at tuhs.org  Sun May 10 01:45:56 2026
From: tuhs at tuhs.org (Ron Natalie via TUHS)
Date: Sat, 09 May 2026 15:45:56 +0000
Subject: [TUHS] PDP-11/20 On eBay
In-Reply-To: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>
References: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>
Message-ID: <em12156213-5fa2-48ce-847b-fdd6e64c71ae@ronnatalie.com>

There’s also an 11/55 up for sale:  
https://www.ebay.com/itm/145952655225

You could actually bring UNIX up on this thing, but it only has a couple 
of RX01 floppies.



------ Original Message ------
>From "segaloco via TUHS" <tuhs at tuhs.org>
To "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Date 5/9/2026 11:40:09 AM
Subject [TUHS] PDP-11/20 On eBay

>Its your "hey this might interest TUHS members and I can't justify the buy" occasional auction mention:
>
>https://www.ebay.com/itm/327147586264
>
>After the link is an auction for a PDP-11/20 with a KE11-A Extended Arithmetic Element.  I don't off the top of my head know if this is enough to be the core of a V1/V2 system, but figured I'd mention it in case any intrepid list members are trying to roll a real V1/V2 setup.  Happy hunting!
>
>- Matt G.

From tuhs at tuhs.org  Sun May 10 02:11:20 2026
From: tuhs at tuhs.org (segaloco via TUHS)
Date: Sat, 09 May 2026 16:11:20 +0000
Subject: [TUHS] PDP-11/20 On eBay
In-Reply-To: <em12156213-5fa2-48ce-847b-fdd6e64c71ae@ronnatalie.com>
References: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>
 <em12156213-5fa2-48ce-847b-fdd6e64c71ae@ronnatalie.com>
Message-ID: <L7MPJmXHP0bEBH6yOKGCpBHCVYPtBQ9iLH8llaiV9Tj8fb342nmTCZ2guJ9S-2ebSwPvMGEbdQZxjzIgCecBJmGUgu7RNvW7jwEIg5KqGAA=@protonmail.com>

On Saturday, May 9th, 2026 at 08:46, Ron Natalie <ron at ronnatalie.com> wrote:

> There’s also an 11/55 up for sale:
> https://www.ebay.com/itm/145952655225
> 
> You could actually bring UNIX up on this thing, but it only has a couple
> of RX01 floppies.

Wowzers can these price tags get eyewatering.  I wonder to what degree UNIX alone influences the PDP-11 resale market vs. the DEC operating systems...

- Matt G.

From tuhs at tuhs.org  Sun May 10 04:25:48 2026
From: tuhs at tuhs.org (Ron Natalie via TUHS)
Date: Sat, 09 May 2026 18:25:48 +0000
Subject: [TUHS] PDP-11/20 On eBay
In-Reply-To: <L7MPJmXHP0bEBH6yOKGCpBHCVYPtBQ9iLH8llaiV9Tj8fb342nmTCZ2guJ9S-2ebSwPvMGEbdQZxjzIgCecBJmGUgu7RNvW7jwEIg5KqGAA=@protonmail.com>
References: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>
 <em12156213-5fa2-48ce-847b-fdd6e64c71ae@ronnatalie.com>
 <L7MPJmXHP0bEBH6yOKGCpBHCVYPtBQ9iLH8llaiV9Tj8fb342nmTCZ2guJ9S-2ebSwPvMGEbdQZxjzIgCecBJmGUgu7RNvW7jwEIg5KqGAA=@protonmail.com>
Message-ID: <em0919fe6f-82d3-4c48-9dcc-b0ce784e04d2@ronnatalie.com>

On the other hand, for a few hundred dollars you can build a Microsoft 
PI simulation of an 11-70 (the PiDP-11/70 kit even comes with a pretty 
cool scale model of the control panel).
I’ve got it chugging away running 2.9 BSD right now (though I can boot 
of the Really Sh-ty Timesharing System for old time’s sake).    One of 
these days, I’ll switch out the kernel to
the BRL one that I spent ten years working on.


------ Original Message ------
>From "segaloco via TUHS" <tuhs at tuhs.org>
To "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Date 5/9/2026 12:11:20 PM
Subject [TUHS] Re: PDP-11/20 On eBay

>On Saturday, May 9th, 2026 at 08:46, Ron Natalie <ron at ronnatalie.com> wrote:
>
>>  There’s also an 11/55 up for sale:
>>  https://www.ebay.com/itm/145952655225
>>
>>  You could actually bring UNIX up on this thing, but it only has a couple
>>  of RX01 floppies.
>
>Wowzers can these price tags get eyewatering.  I wonder to what degree UNIX alone influences the PDP-11 resale market vs. the DEC operating systems...
>
>- Matt G.

From tuhs at tuhs.org  Mon May 11 07:28:31 2026
From: tuhs at tuhs.org (Kevin Bowling via TUHS)
Date: Sun, 10 May 2026 14:28:31 -0700
Subject: [TUHS] PDP-11/20 On eBay
In-Reply-To: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>
References: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>
Message-ID: <CAK7dMtAYijyG=oH7AGcCrvM_KHcwHOyB1vZjA9Er5HQE5JsyfA@mail.gmail.com>

On Sat, May 9, 2026 at 8:40 AM segaloco via TUHS <tuhs at tuhs.org> wrote:
>
> Its your "hey this might interest TUHS members and I can't justify the buy" occasional auction mention:
>
> https://www.ebay.com/itm/327147586264
>
> After the link is an auction for a PDP-11/20 with a KE11-A Extended Arithmetic Element.  I don't off the top of my head know if this is enough to be the core of a V1/V2 system, but figured I'd mention it in case any intrepid list members are trying to roll a real V1/V2 setup.  Happy hunting!

If you want to play around with stuff like this but can't, I'll plug
my friend Dave McGuire's Large Scale Systems Museum in the Pittsburgh
area.  It's really worth a trek if you enjoy unix history, you can
walk up and boot unix on a PDP or VAX.  Ken Shariff did a review a
while back https://www.righto.com/2019/10/a-visit-to-large-scale-systems-museum.html.
The official website is https://www.mact.io/

> - Matt G.

From tuhs at tuhs.org  Mon May 11 08:22:25 2026
From: tuhs at tuhs.org (Clem Cole via TUHS)
Date: Sun, 10 May 2026 18:22:25 -0400
Subject: [TUHS] PDP-11/20 On eBay
In-Reply-To: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>
References: <EqMOVoBQR5iHCI2rQCTcWZV6mV2qSem9HJfLEZ5IvXvxl-n-gNFtUUctt1GPVPntRHB1P6E7l4ZVNb4cySyY6xx4O30_OYfbZBE1p4S5CH4=@protonmail.com>
Message-ID: <CAC20D2Ov4oZqoKQ_4_kLSB8Hqtq_sk1Qc1wQ1fchJ4-xk3a-yw@mail.gmail.com>

On Sat, May 9, 2026 at 11:40 AM segaloco via TUHS <tuhs at tuhs.org> wrote:

> ...

After the link is an auction for a PDP-11/20 with a KE11-A Extended
> Arithmetic Element.  I don't off the top of my head know if this is enough
> to be the core of a V1/V2 system, but figured I'd mention it in case any
> intrepid list members are trying to roll a real V1/V2 setup.  Happy hunting!
>
It needs KE11-A, as Dennis required it for his compiler, so that's a check
box.  But there are other issues: the earliest versions of the PDP-11/20
did not have an MMU (or user/supervisor), but did have a maximum memory of
56K for a stock 11/20.  Dennis describes the early issues of running
without an MMU and actually what happened after they got one (KS-11):
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/odd.html

So, to really run early Unix on the 121/20, you need a KS-11 and a full
complement of Unibus memory (256K).  None of these seems to have been found
in the wild, much less the documentation.  Supnik's MIMIC supports it, and
we also have some early UNIX code. Together what we know can be found here:
https://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option

From tuhs at tuhs.org  Tue May 12 18:19:25 2026
From: tuhs at tuhs.org (Folkert van Heusden via TUHS)
Date: Tue, 12 May 2026 10:19:25 +0200
Subject: [TUHS] fork
Message-ID: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>

Hello,

I succeeded in implementing DEQNA support in my emulator so I could put 
it on-line with a simple HTTP server on BSD 2.11.

Now something unexpected is happening: after a request, a "<defunct>" 
proces is left in the process list. Usually that is caused by a fork() 
not being join()ed afterwards. But in main() of httpdp I invoke 
signal(SIGCHLD, SIG_IGN); so I thought I took care of that?

Could it be that old UNIX systems do not allow the signal-construction 
for that? Or is something else going wrong?

regards

p.s. it is on http://pdp.komputilo.nl:8080/ (behind a NAT router) and it 
takes quite a while to serve pages :-)

-- 
www.vanheusden.com [1]

Links:
------
[1] http://www.vanheusden.com

From tuhs at tuhs.org  Tue May 12 18:39:38 2026
From: tuhs at tuhs.org (Warren Toomey via TUHS)
Date: Tue, 12 May 2026 18:39:38 +1000
Subject: [TUHS] fork
In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
Message-ID: <agLnSpVZJlXORsQY@minnie.tuhs.org>

On Tue, May 12, 2026 at 10:19:25AM +0200, Folkert van Heusden via TUHS wrote:
> Now something unexpected is happening: after a request, a "<defunct>" proces
> is left in the process list. Usually that is caused by a fork() not being
> join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD,
> SIG_IGN); so I thought I took care of that?

I'm going to take an educated guess. You fork() a child, but in the
parent process you never wait()? Thus, once the child exit()s, no
process collects the exit status and so the child becomes a zombie
process. Eventually the init process will reap your child's exit status.

signal(SIGCHLD, SIG_IGN) is only going to make the parent ignore any
change to the child's status; it doesn't take the child out of the
process table. Technically (I believe), the child's memory and other
resources are freed when it exit(s), but the process-id, the exit status
and the slot in the process table stay there until someone wait(s).

Cheers, Warren

From tuhs at tuhs.org  Tue May 12 20:55:09 2026
From: tuhs at tuhs.org (Ron Natalie via TUHS)
Date: Tue, 12 May 2026 10:55:09 +0000
Subject: [TUHS] fork
In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
Message-ID: <em79b7cebf-45af-4c94-b876-3989cfacc13c@ronnatalie.com>

Processes stay zombines until someone waits for them.    If their parent 
is alive, it will have to execute a wait() to get the status.   If the 
parent is dead, prossess 1 (historically INIT) will becoe the parent for 
the purpose of wain().

Note that there are differing SIGCHLD / SIGCLD behaviors,    In addition 
to the sitnal being caught telling the process that there’s something to 
wait on, some systems take specifally setting SIGCHLD to SIG_IGN as an 
indiation
that you don’t ever want to wait and any children when they die will 
immediately go away without entering the zombine state.


From tuhs at tuhs.org  Tue May 12 21:18:48 2026
From: tuhs at tuhs.org (Peter Jeremy via TUHS)
Date: Tue, 12 May 2026 21:18:48 +1000
Subject: [TUHS] fork
In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
Message-ID: <agMMmEzc0ixjT9Ig@server.rulingia.com>

On 2026-May-12 10:19:25 +0200, Folkert van Heusden via TUHS <tuhs at tuhs.org> wrote:
>Now something unexpected is happening: after a request, a "<defunct>" proces
>is left in the process list. Usually that is caused by a fork() not being
>join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD,
>SIG_IGN); so I thought I took care of that?

For "modern" Unixes (e.g. FreeBSD and Linux), there's a SA_NOCLDWAIT flag
for sigaction(2) that explicitly says setting SIGCHLD to SIG_IGN means that
child processes will not become zombies but will instead be implicitly
reaped immediately.

This doesn't exist in BSD2.11 and, as far as I can tell from looking
through the sources, there's no equivalent behaviour: When a process exits,
the process becomes a zombie and the parent is sent a SIGCHLD (see
kern_exit.c::exit()).  In psignal(), if a signal is marked SIG_IGN, the
signal is completely ignored - there's no special handling of SIGCHLD.
There's no obvious code to clean up zombie processes if the parent doesn't
wait() for them.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20260512/accef5c0/attachment.sig>

From tuhs at tuhs.org  Tue May 12 22:38:14 2026
From: tuhs at tuhs.org (rob--- via TUHS)
Date: Tue, 12 May 2026 13:38:14 +0100
Subject: [TUHS] fork
In-Reply-To: <agMMmEzc0ixjT9Ig@server.rulingia.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
 <agMMmEzc0ixjT9Ig@server.rulingia.com>
Message-ID: <C5DC67A1-A2DA-40F9-A128-8D84A2B3068B@atvetsystems.com>

I remember having to use a double fork() in the 90’s which I think maybe to solve a problem like this that the top process can fork() and wait() but the child fork(’s again and exits so that the death of the grandchild process gets cleaned by by init.

Regards, Rob.

> On 12 May 2026, at 12:18, Peter Jeremy via TUHS <tuhs at tuhs.org> wrote:
> 
> On 2026-May-12 10:19:25 +0200, Folkert van Heusden via TUHS <tuhs at tuhs.org> wrote:
>> Now something unexpected is happening: after a request, a "<defunct>" proces
>> is left in the process list. Usually that is caused by a fork() not being
>> join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD,
>> SIG_IGN); so I thought I took care of that?
> 
> For "modern" Unixes (e.g. FreeBSD and Linux), there's a SA_NOCLDWAIT flag
> for sigaction(2) that explicitly says setting SIGCHLD to SIG_IGN means that
> child processes will not become zombies but will instead be implicitly
> reaped immediately.
> 
> This doesn't exist in BSD2.11 and, as far as I can tell from looking
> through the sources, there's no equivalent behaviour: When a process exits,
> the process becomes a zombie and the parent is sent a SIGCHLD (see
> kern_exit.c::exit()).  In psignal(), if a signal is marked SIG_IGN, the
> signal is completely ignored - there's no special handling of SIGCHLD.
> There's no obvious code to clean up zombie processes if the parent doesn't
> wait() for them.
> 
> -- 
> Peter Jeremy


From tuhs at tuhs.org  Wed May 13 00:18:48 2026
From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS)
Date: Tue, 12 May 2026 16:18:48 +0200
Subject: [TUHS] fork
In-Reply-To: <C5DC67A1-A2DA-40F9-A128-8D84A2B3068B@atvetsystems.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
 <agMMmEzc0ixjT9Ig@server.rulingia.com>
 <C5DC67A1-A2DA-40F9-A128-8D84A2B3068B@atvetsystems.com>
Message-ID: <20260512141848.eLpWpVzc@steffen%sdaoden.eu>

rob--- via TUHS wrote in
 <C5DC67A1-A2DA-40F9-A128-8D84A2B3068B at atvetsystems.com>:
 |> On 12 May 2026, at 12:18, Peter Jeremy via TUHS <tuhs at tuhs.org> wrote:
 |> 
 |> On 2026-May-12 10:19:25 +0200, Folkert van Heusden via TUHS <tuhs at tuhs.o\
 |> rg> wrote:
 |>> Now something unexpected is happening: after a request, a "<defunct>" \
 |>> proces
 |>> is left in the process list. Usually that is caused by a fork() \
 |>> not being
 |>> join()ed afterwards. But in main() of httpdp I invoke signal(SIGCHLD,
 |>> SIG_IGN); so I thought I took care of that?
 |> 
 |> For "modern" Unixes (e.g. FreeBSD and Linux), there's a SA_NOCLDWAIT flag
 |> for sigaction(2) that explicitly says setting SIGCHLD to SIG_IGN \
 |> means that
 |> child processes will not become zombies but will instead be implicitly
 |> reaped immediately.
 |> 
 |> This doesn't exist in BSD2.11 and, as far as I can tell from looking
 |> through the sources, there's no equivalent behaviour: When a process \
 |> exits,
 |> the process becomes a zombie and the parent is sent a SIGCHLD (see
 |> kern_exit.c::exit()).  In psignal(), if a signal is marked SIG_IGN, the
 |> signal is completely ignored - there's no special handling of SIGCHLD.
 |> There's no obvious code to clean up zombie processes if the parent \
 |> doesn't
 |> wait() for them.

 |I remember having to use a double fork() in the 90’s which I think \
 |maybe to solve a problem like this that the top process can fork() \
 |and wait() but the child fork(’s again and exits so that the death \
 |of the grandchild process gets cleaned by by init.

In a communication this year a friendly Russian said

  By the way, I thought that double fork is something useless for dozens
  of years. As I remember, the second fork() was needed because of
  relatively old SysV-like systems still gave more than enough permissions
  to the child process after the first fork(). As I remember Richard Stevens
  book, BSDs never required second fork. fork()+setsid() were enough. But
  I guess maybe Linux inherited SysV-like behaviour/issue and that is why
  second fork() is needed.

and he refers to advanced_pogramming_in_the_unix_environment,
13.3, Coding Rules, on daemonization:

  2. Call fork and have the parent exit. This does several
  things. First, if the daemon was started as a simple shell
  command, having the parent terminate makes the shell think that
  the command is done.  Second, the child inherits the process
  group ID of the parent but gets a new process ID, so we're
  guaranteed that the child is not a process group leader. This is
  a prerequisite for the call to setsid that is done next.

  3. Call setsid to create a new session. The three steps listed
  in Section 9.5 occur. The process (a) becomes a session leader
  of a new session, (b) becomes the process group leader of a new
  process group, and (c) has no controlling terminal.

  Under System V–based systems, some people recommend calling fork
  again at this point and having the parent terminate. The second
  child continues as the daemon. This guarantees that the daemon
  is not a session leader, which prevents it from acquiring
  a controlling terminal under the System V rules (Section
  9.6). Alternatively, to avoid acquiring a controlling terminal,
  be sure to specify O_NOCTTY whenever opening a terminal device.

    [Which in turn is

      POSIX.1 leaves the choice of the mechanism used to allocate
      a controlling terminal up to each individual
      implementation. We'll show the actual steps in Section 19.4.

      Systems derived from UNIX System V allocate the controlling
      terminal for a session when the session leader opens the first
      terminal device that is not already associated with
      a session. This assumes that the call to open by the session
      leader does not specify the O_NOCTTY flag (Section 3.3).

      BSD-based systems allocate the controlling terminal for
      a session when the session leader calls ioctl with a request
      argument of TIOCSCTTY (the third argument is a null
      pointer). The session cannot already have a controlling
      terminal for this call to succeed. (Normally, this call to
      ioctl follows a call to setsid, which guarantees that the
      process is a session leader without a controlling terminal.)
      The POSIX.1 O_NOCTTY flag to open is not used by BSD-based
      systems, except in compatibility-mode support for other
      systems.]

(He mentioned this, i think, because i do double fork in some
stupid little thing (greylister), but this is because of Linux and
FreeBSD sandboxing .. and the "necessity" to separate the actual
syslog interaction, on Linux mostly because of who knows what
syslog internally needs .. and fd is opened delayed etc etc etc.
OpenBSD has added a syslog system call which makes that topic
easy.  Btw, and imho, Linux seccomp should really have a way to
simply declare a bitmask of allowed or forbidden system calls,
instead of these lengthy tit-and-tat things.  Maybe landlock,
.. but this is off topic, of course.)

New FreeBSD and Linux offer possibilities to declare the "reaper"
process to which PIDs get reparented.  FreeBSD with iteration
over, and all that.  (Then again this is not well integrated in
respect to P(luggable)A(uthentication)M(odules), which is pretty
well used on Linux, FreeBSD, NetBSD, and offers sessions, but any
idiot -- even myself that is -- can "escape" from these sessions
with a simple I/O-redirected shell command, effectively ending up
with init(8), because they do not use this reaper functionality.
On Linux, you have that systemd monster, which surely does this
the right way, on top, say.  There is finit, i think it also tries
to go cgroup + X, but in how far it does X, aka capabilities,
overlay mounts (for eg /tmp/), i would have to look again.  BSDs,
anyway not.  The mentioned guy swears on s6 / runit, which is then
also some approach, more UNIX-like, that much is plain.  Puh.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From tuhs at tuhs.org  Wed May 13 00:32:18 2026
From: tuhs at tuhs.org (Phil Budne via TUHS)
Date: Tue, 12 May 2026 10:32:18 -0400
Subject: [TUHS] fork
In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
Message-ID: <202605121432.64CEWIqd038238@ultimate.com>

> But in main() of httpdp I invoke 
> signal(SIGCHLD, SIG_IGN); so I thought I took care of that?
>
> Could it be that old UNIX systems do not allow the signal-construction 
> for that? Or is something else going wrong?

I seem to recall that the magic property of discarding zombies if
SIGCHLD is ignored was introduced by AT&T (in System V?), later made
user controllable in one of the Grand Unification effort [SUSv2?]

I also have vague recollection of some signal define having different
spellings in the different camps, but can't find any trace of it
having been SIGCHILD [sic]!

From tuhs at tuhs.org  Wed May 13 00:51:30 2026
From: tuhs at tuhs.org (Chet Ramey via TUHS)
Date: Tue, 12 May 2026 10:51:30 -0400
Subject: [TUHS] fork
In-Reply-To: <202605121432.64CEWIqd038238@ultimate.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
 <202605121432.64CEWIqd038238@ultimate.com>
Message-ID: <309ff4ac-00f9-4d87-9099-41267a8cf798@case.edu>

On 5/12/26 10:32 AM, Phil Budne via TUHS wrote:

> I also have vague recollection of some signal define having different
> spellings in the different camps, but can't find any trace of it
> having been SIGCHILD [sic]!

SIGCHLD vs. SIGCLD.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/

From tuhs at tuhs.org  Wed May 13 02:51:52 2026
From: tuhs at tuhs.org (Folkert van Heusden via TUHS)
Date: Tue, 12 May 2026 18:51:52 +0200
Subject: [TUHS] fork
In-Reply-To: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
Message-ID: <9de657ea744fea9717775d533724933d@vanheusden.com>

Thanks to everybody who responded.

After a waitpid() in the signal handler, all is good.
Never realised that you could do that in a signal handler!
With that, it runs a lot longer before I need to restart something :-)
Strange thing though is that I need to do e.g. a ping from bsd to $world 
to keep things going. If not, it keeps running but won't respond anymore 
to network traffic.


regards

From tuhs at tuhs.org  Wed May 13 03:12:29 2026
From: tuhs at tuhs.org (Dan Cross via TUHS)
Date: Tue, 12 May 2026 13:12:29 -0400
Subject: [TUHS] fork
In-Reply-To: <9de657ea744fea9717775d533724933d@vanheusden.com>
References: <9c0a5b114cb4e4a293be81543c25b1bc@vanheusden.com>
 <9de657ea744fea9717775d533724933d@vanheusden.com>
Message-ID: <CAEoi9W4NOT-o5Pop7KZkbrY45itN42NAQN2rpqz_N3Yvnk6nOg@mail.gmail.com>

On Tue, May 12, 2026 at 12:52 PM Folkert van Heusden via TUHS
<tuhs at tuhs.org> wrote:
>[snip]
> Strange thing though is that I need to do e.g. a ping from bsd to $world
> to keep things going. If not, it keeps running but won't respond anymore
> to network traffic.

Hmm. Off the top of my head, I wonder if it's an ARP issue.
Is your emulator passing ARP requests for thye BSD system correctly?

        - Dan C.

