Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Computer Old Farts Followers <coff@tuhs.org>,
	"nw.johnson@ieee.org" <nw.johnson@ieee.org>,
	simh@groups.io
Subject: [COFF] Re: [simh] Old VAX/VMS Tapes
Date: Sat, 30 Dec 2023 21:27:18 -0500	[thread overview]
Message-ID: <CAC20D2MW2FLUGmVPnffupUypy0iQ1sFre3AeWaS8pEnH3jnYtQ@mail.gmail.com> (raw)
In-Reply-To: <75e8f333-98fc-45da-b109-fedaa9d78fdb@ieee.org>

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

We should move to COFF (cc’ed) for any further discussion. This is way off
topic for simh.

Below

Sent from a handheld expect more typos than usual


On Sat, Dec 30, 2023 at 7:59 PM Nigel Johnson MIEEE via groups.io
<nw.johnson=ieee.org@groups.io> wrote:

> First of all, 7-track vs 9-yrack - when you are streaming in serpentine
> mode, it is whatever you can fit into the tape width having regard to the
> limitations of the stepper motor accuracy.
>
Agreed.  It’s the physical size of head and encoding magnetics.  Parallel
you have n heads together all  reading or writing together into n analog
circuits.   A rake across the ground if you will.  Serial of course its
like a single pencil line with the head on a servo starting in the center
of the tape and when you hit the physical eot move it up or down as
appropriate.


It is nothing to do with the number of bits per data unit.
>
I did not say that or imply it.   But variable vs. fixed blocking has
implications on both mechanical requirements and ends up being reflected in
how the sw handles it.  Traditional 9-track allows you to mix record sizes
on each tape.  Streamer formats don’t traditionally allow that because they
restrict / remove inter record gaps in the same manner 9-track supports.
This increases capacity of the tape (less waste).

Just for comparison at 6250 BPI a traditional 2400’ ½” tape writing fixed
blocks of 10240 8-bit bytes gets about 150Mbytes.  A ¼” DC-6150 tape using
QIC-150 only one forth the length and half as wide gets the same capacity
and they both use the same core scheme to encode the bits.  QIC writes
smaller bits and wastes less tape with IRCs.

That all said, Looking at the TK25 specs besides being 11 tracks it is also
supports a small number different block sizes (LRECL) - unlike QIC.
Nothing like 9-track which can handle a large range of LRECLs.  What I
don’t see in the TK25 is if you can mix them on a tape or if that is coded
once for each tape as opposed in each record.


Btw while I don’t think ansi condones it, some 9-track units like the
Storage Tek ones could not only write different LRECLs but could write
using different encoding (densities) on the same medium.  This sad trick
confused many drives when you moved the tape to a drive that could not.  I
have some interesting customer stories living those issues.  But I digress …

FWIW As I said before do have a lot of experience with what it takes to
support this stuff and what you have to do decode it, the drivers for same
et al.   I never considered myself a tape expert- there are many the know
way more than I - but I have lived, experienced and had to support a number
of these systems and have learned the hard way about how these schemes can
go south when trying to recover data.

Back in the beginning of my career, we had Uniservo VIC drives which were
> actually 7-bit parallel! (256, 556, and 800 bpi! NRZI
>
Yep same here. ½” was 5, 7 and 9 bits in parallel originally.  GE-635 has
in the late 1960s then and a IBM shop in the early 70s.  And of course saw
my favorite tapes of all - original DEC tape.  I’ve  also watched things
change with serial and the use of serpentine encoding.

You might find it amusing — any early 1980s Masscomp machines had a special
½” drive that had a huge number serpentine tracks I’ve forgotten the exact
amount. They used traditional 1/2” spools from 3M and the like but r/w was
custom to the drive.    I’ve forgotten the capacity but at the time it was
huge. What I remember it was much higher capacity and reliability than
exabyte which at the time was the capacity leader. The USAF AWACS planes
had 2 plus a spare talking to the /700 systems doing the I/O - they were
suckling up everything in the air and recording it as digital signals. The
tape units were Used to record all that data.  An airman spends his/whole
time loading and unloading tapes.     Very cool system.


> Some things about the 92192 drive:  it was 8" cabinet format in a 5.25
> inch world so needed an external box.  It also had an annoying habit, given
> Control Data's proclivity for perfection, that when you put a cartridge in,
> it ran it back and forth for five minutes before coming ready to ensure
> even tension on the tape!
>
> The formatter-host adapter bus was not QIC36, so Emulex had to make a
> special controller, the TC05, to handle the CDC Proprietary format. The
> standard was QIC-36, although I think that Tandberg had a standard of their
> own.
>
Very likely.  When thoses all came on the scene there were a number of
interfaces and encoding schemes. I was not involved in any of the politics
but QIC ended up as the encoding standard and SCSI the interface

IIRC the first QIC both Masscomp and Apollo used was QIC-36 via a SCSI
converter board SCS made for both of us.  I don’t think Sun used it.  Later
Archive and I think Wangtek made SCSI interface standard on the drives.



> I was wrong about the 9-track versus 7, the TC05/sentinel combination
> writes 11 tracks!  The standard 1/4' cartridge media use QIC24, which
> specifies 9 tracks. I just knew it was not 9!
>
It also means it was not a QIC standard as I don’t believe they had one
between QIC-24-DC and QIC-120-DC.   Which I would think means that if this
tape came from a TK25 I doubt either Steve or my drives will read it -
he’ll need to find someone with a TK25 - which I have never seen
personally.




> That's all I know!
>
fair enough

Clem_._,_._,_

>

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

       reply	other threads:[~2023-12-31  2:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <656c72ae-2b6e-487c-a7bc-6e3a3896b49f@ieee.org>
     [not found] ` <53587999-897f-4b69-b476-b1c83dfaf816@ieee.org>
     [not found]   ` <2cafc131-3e5d-4bf1-b0ee-537e3ed0f4cd@ieee.org>
     [not found]     ` <CAC20D2O+=0axoX1zCGbFvs=hHijENyD-q16-kQA5Dw84dOYLiQ@mail.gmail.com>
     [not found]       ` <75e8f333-98fc-45da-b109-fedaa9d78fdb@ieee.org>
2023-12-31  2:27         ` Clem Cole [this message]
     [not found]         ` <17A5C98F69111E59.18542@groups.io>
2023-12-31 19:29           ` Clem Cole
     [not found]           ` <17A601627CB0546A.18542@groups.io>
2023-12-31 21:38             ` Clem Cole

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=CAC20D2MW2FLUGmVPnffupUypy0iQ1sFre3AeWaS8pEnH3jnYtQ@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=coff@tuhs.org \
    --cc=nw.johnson@ieee.org \
    --cc=simh@groups.io \
    /path/to/YOUR_REPLY

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

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