[TUHS] Choice of Tape Format for BTL UNIX Distro

[Clem Cole via TUHS]

Most welcome.  Glad it was helpful.

I’ve actually been considered a tape wizard by many of my friends.  It
really goes back to learning my learn how to handle tapes on TSS/360 an
Exec 8 on the Univac, early in my career.  The later had three 7-track
drives (5-20 M 6-bit bytes)  and very little drum/disk.   I still can speak
a bit of the language with term like LRECL [Logical RECord length - IBM
speak for block size].  Tapes often had file systems on them.  Technically
that can be read or written in both directions in the old mainframe world.

Sent from a handheld expect more typos than usual


On Wed, Apr 1, 2026 at 6:07 PM Peter Yardley <peter.martin.yardley at gmail.com>
wrote:

> Thanks Clem
>
> My submissions to the list were getting lost.
>
> Been about 30 years since I last used tape in anger. Your answer was quite
> comprehensive.
>
> > On 1 Apr 2026, at 11:11 pm, Clem Cole <clemc at ccc.com> wrote:
> >
> > Take a look at what I sent to whole list. If you have questions let me
> know off list. Clem
> >
> > Sent from a handheld expect more typos than usual
> >
> >
> > On Wed, Apr 1, 2026 at 6:11 AM Peter Yardley via TUHS <tuhs at tuhs.org>
> wrote:
> > Thanks I’ll try sending this to the list.
> >
> > > Begin forwarded message:
> > >
> > > From: arnold at skeeve.com
> > > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro
> > > Date: 1 April 2026 at 8:41:04 pm AEDT
> > > To: peter.martin.yardley at gmail.com, arnold at skeeve.com
> > >
> > > I don't see the list in the To: or CC:
> > >
> > > Thanks for confirming my memory that 6400 BPI drives existed.
> > >
> > > Peter Yardley <peter.martin.yardley at gmail.com> wrote:
> > >
> > >> Don’t know if this will hit the list.
> > >>
> > >> My memory is we had a 1600 BPI tape drive. Of course that would have
> read 800BPi tapes.
> > >>
> > >> The 6400 BPI drives were much more expensive so not everyone had one.
> > >>
> > >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS <tuhs at tuhs.org>
> wrote:
> > >>>
> > >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you
> > >>> eight bits of data plus a parity bit.
> > >>>
> > >>> By the mid-80s, 1600 BPI was pretty common for the same media, so
> > >>> the BSD distributions might have been 1600 BPI tapes.
> > >>>
> > >>> I think at some point 9 track tape drives hit something like 6400
> BPI,
> > >>> but I may be hallucinating the memory.
> > >>>
> > >>> HTH,
> > >>>
> > >>> Arnold
> > >>>
> > >>> segaloco via TUHS <tuhs at tuhs.org> wrote:
> > >>>
> > >>>> Surprise surprise, another hyper-specific topic incoming.  I am
> curious
> > >>>> if anyone on-list can provide insight on this topic.  Setting Up
> Unix -
> > >>>> Seventh Edition indicates:
> > >>>>
> > >>>>> The tape is 9-track 800 BPI...
> > >>>>
> > >>>> Was this a matter of convention given the general computing
> ecosystem at
> > >>>> the time, or was this more driven by Bell System standards for
> magtape?
> > >>>>
> > >>>> I find myself curious as I recently procured a 7-track 556 BPI
> transport
> > >>>> which, while not applicable to V7 UNIX tapes as so described, has me
> > >>>> itching to explore the world of magtape further, including
> eventually
> > >>>> tracking down a 9-track supporting the necessary BPI should another
> UNIX
> > >>>> tape needing preservation surface.
> > >>>>
> > >>>> I also recently got a QIC drive (not the right size for the early
> 90s
> > >>>> BTL tapes I have) and am exploring repurposing the read head to yank
> > >>>> data off these janky QIC tapes I have.  Needless to say, magnetic
> tape
> > >>>> media and preservation is on the mind lately.
> > >>>>
> > >>>> Further on the subject of UNIX tapes though, was there any regular
> > >>>> shipment of other media not matching this description or was it
> pretty
> > >>>> settled that
> > >>>>
> > >>>> order_unix()
> > >>>>
> > >>>> has a return type of
> > >>>>
> > >>>> mt_track_9_bpi_800_t
> > >>>>
> > >>>> ?
> > >>>>
> > >>>> - Matt G.
> > >>
> > >>
> > >> .1.3.6.1.4.1.8852.4.2
> > >> Peter Yardley
> > >> peter.martin.yardley at gmail.com
> >
> >
> > .1.3.6.1.4.1.8852.4.2
> > Peter Yardley
> > peter.martin.yardley at gmail.com
> >
>
>
> .1.3.6.1.4.1.8852.4.2
> Peter Yardley
> peter.martin.yardley at gmail.com
>
>