[COFF] Re: [simh] Old VAX/VMS Tapes

[COFF] Re: [simh] Old VAX/VMS Tapes

[Clem Cole]

[-- 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 --]

[COFF] Re: [simh] Old VAX/VMS Tapes

[Clem Cole]

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

Small PS below...

On Sat, Dec 30, 2023 at 9:27 PM Clement T Cole via groups.io <clemc=
ccc.com@groups.io> wrote:

>
> 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).
>

In my explanation, I may have been a tad confusing.   When I say fixed
records -- I mean on-tape fixed records, what the QIC-24/120/150 standard
refers to as: "*A group of consecutive bits comprising of a preamble, data
block marker, a single data block, block address and CRC and postamble*"
[the standard previous defines a data black os 512 consecutive bytes] --*
i.e*., if you put an o'scope on the tape head and looked at the bit
stream (see page 16 of QIC-120 Rev F -  Section 5 "Recorded Block" for a
picture of this format -- note is can only address 2^20 blocks per track,
but it supports addressing to 256 tracks -- with 15 tracks of QIC-120 that
means 15728640 unique 512-byte blocks).

STOP/STOP does something similar but encodes the LRECL used [I don't have
the ANSI tape standard handy - but I remember seeing a wonderful picture of
all this from said documents when I first was educated about tapes in my
old IBM days ~50 years ago].   After each record, STOP/STOP needs an
"Inter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down time
before continuing the bit stream of the next data block.  The IRC distance
is something like 5-10 mm [which is a great deal compared to the size of a
bit when using GCR encoding (which is what 6250 BPI and QIC both use).
These gaps take space (capacity) from the tape, so people tend to write
with larger blocking factors [UNIX traditionally uses 10240 bytes- other
systems use other values - as I said, I believe the standard says the max
is 64K bytes).

Since streamers (like QIC tape) are supposed to be continuous, the QIC
inter-records gaps resemble fixed disk records and can be extremely small.
Remember, each bit is measured in micrometers -- about *2 micrometers*,
IIRC for QIC and around 10 for ½" formats -- again, and I would need to
check the ANSI spec, which is not handy.  But this is a huge space savings
even with a smallish block (512) -- again - this was lifted from disk
technology of the day which had often standardized on 512 8-bit byte blocks
by then.

BTW: this is again why I suspect a TK25 tape is not going to be able to
read on QIC-24/120/150 drive if, indeed, page 1-5 of the TK25 user manual
says it supports four different block sizes [1K/2K/4K/8K].   First, the
data block format would have to be variable to 4 sizes, and second, the
preamble would need to encode and write what size block to expect on
read. Unfortunately, that document does not say much more about the
physical tape format other than it can use cartridges  "similar to ANSI
Standard X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11
tracks, 8000 bpi" recording density (/w 10000 flux reversals per in), using
a "single track NRZI dat in a serpentine pattern, with 4-5 run length
limited code similar to GCR."

That said, most modern SW will allow you to *write* different size record
sizes (LRECL) in the user software, but the QIC drives and I believe things
like DAT and Exabyte will only write 512-byte blocks, so somewhere between
your user program and tape itself, the write will be broken into N 512 byte
blocks and then pad (with null is typical) the last block to 512 bytes.
 My memory is the QIC standard is silent on where that is done, but I
suspect it's done in the controller and the driver is forced to send it
512-byte blocks.

So, while you may define blocks of different sizes, unlike ½", it will
always be written as 512-byte blocks.

That said, using larger record sizes in your application SW can have huge
performance wins (which I mentioned in my first message) - *e.g.*,  keeping
the drive streaming as more user data has been locked down in memory for a
DMA. But by the time the driver and the controller are finished, it's fixed
512-byte blocks on the tape.


One other thing is WRT to QIC, which differs from other schemes.  I
previously mentioned tape files - a feature of the ½" physical tape formats
not typically supported for QIC tapes.  QIC has an interesting feature that
allows a block to be rewritten and replaced later on the tape (see the
section of spec/you user manual WRT for "rewritten" or "replacement
"blocks).    I've forgotten all the details, but I seem to remember that
features were why multiple tape files were difficult to implement.
 Someone who knows more about tapes may remember the details/be able to
explain -- I remember dealing with tape files was a PITA in QIC, and the
logic in a standard ½" tape driver could not be just cloned for the QIC
driver.
ᐧ
ᐧ
ᐧ

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

[COFF] Re: [simh] Old VAX/VMS Tapes

[Clem Cole]

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

Dyslexia sucks... sorry, if it was not obvious, please globally substitute
  s:STOP/STOP:START/STOP:
ᐧ

On Sun, Dec 31, 2023 at 2:30 PM Clement T Cole via groups.io <clemc=
ccc.com@groups.io> wrote:

> Small PS below...
>
> On Sat, Dec 30, 2023 at 9:27 PM Clement T Cole via groups.io <clemc=
> ccc.com@groups.io> wrote:
>
>>
>> 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).
>>
>
> In my explanation, I may have been a tad confusing.   When I say fixed
> records -- I mean on-tape fixed records, what the QIC-24/120/150 standard
> refers to as: "*A group of consecutive bits comprising of a preamble,
> data block marker, a single data block, block address and CRC and postamble*"
> [the standard previous defines a data black os 512 consecutive bytes] --*
> i.e*., if you put an o'scope on the tape head and looked at the bit
> stream (see page 16 of QIC-120 Rev F -  Section 5 "Recorded Block" for a
> picture of this format -- note is can only address 2^20 blocks per track,
> but it supports addressing to 256 tracks -- with 15 tracks of QIC-120 that
> means 15728640 unique 512-byte blocks).
>
> STOP/STOP does something similar but encodes the LRECL used [I don't have
> the ANSI tape standard handy - but I remember seeing a wonderful picture of
> all this from said documents when I first was educated about tapes in my
> old IBM days ~50 years ago].   After each record, STOP/STOP needs an
> "Inter-Record-Gap" (IRC) to allow for the motor's spin-up/spin-down time
> before continuing the bit stream of the next data block.  The IRC distance
> is something like 5-10 mm [which is a great deal compared to the size of a
> bit when using GCR encoding (which is what 6250 BPI and QIC both use).
> These gaps take space (capacity) from the tape, so people tend to write
> with larger blocking factors [UNIX traditionally uses 10240 bytes- other
> systems use other values - as I said, I believe the standard says the max
> is 64K bytes).
>
> Since streamers (like QIC tape) are supposed to be continuous, the QIC
> inter-records gaps resemble fixed disk records and can be extremely small.
> Remember, each bit is measured in micrometers -- about *2 micrometers*,
> IIRC for QIC and around 10 for ½" formats -- again, and I would need to
> check the ANSI spec, which is not handy.  But this is a huge space savings
> even with a smallish block (512) -- again - this was lifted from disk
> technology of the day which had often standardized on 512 8-bit byte blocks
> by then.
>
> BTW: this is again why I suspect a TK25 tape is not going to be able to
> read on QIC-24/120/150 drive if, indeed, page 1-5 of the TK25 user manual
> says it supports four different block sizes [1K/2K/4K/8K].   First, the
> data block format would have to be variable to 4 sizes, and second, the
> preamble would need to encode and write what size block to expect on
> read. Unfortunately, that document does not say much more about the
> physical tape format other than it can use cartridges  "similar to ANSI
> Standard X3.55-1982" (which is a 3M DC-600A tape cartridge), has "11
> tracks, 8000 bpi" recording density (/w 10000 flux reversals per in), using
> a "single track NRZI dat in a serpentine pattern, with 4-5 run length
> limited code similar to GCR."
>
> That said, most modern SW will allow you to *write* different size record
> sizes (LRECL) in the user software, but the QIC drives and I believe things
> like DAT and Exabyte will only write 512-byte blocks, so somewhere between
> your user program and tape itself, the write will be broken into N 512 byte
> blocks and then pad (with null is typical) the last block to 512 bytes.
>  My memory is the QIC standard is silent on where that is done, but I
> suspect it's done in the controller and the driver is forced to send it
> 512-byte blocks.
>
> So, while you may define blocks of different sizes, unlike ½", it will
> always be written as 512-byte blocks.
>
> That said, using larger record sizes in your application SW can have huge
> performance wins (which I mentioned in my first message) - *e.g.*,
> keeping the drive streaming as more user data has been locked down in
> memory for a DMA. But by the time the driver and the controller are
> finished, it's fixed 512-byte blocks on the tape.
>
>
> One other thing is WRT to QIC, which differs from other schemes.  I
> previously mentioned tape files - a feature of the ½" physical tape formats
> not typically supported for QIC tapes.  QIC has an interesting feature that
> allows a block to be rewritten and replaced later on the tape (see the
> section of spec/you user manual WRT for "rewritten" or "replacement
> "blocks).    I've forgotten all the details, but I seem to remember that
> features were why multiple tape files were difficult to implement.
>  Someone who knows more about tapes may remember the details/be able to
> explain -- I remember dealing with tape files was a PITA in QIC, and the
> logic in a standard ½" tape driver could not be just cloned for the QIC
> driver.
> ᐧ
> ᐧ
> ᐧ
> _._,_._,_
> ------------------------------
> Groups.io Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#3631) <https://groups.io/g/simh/message/3631> | Reply
> To Group
> <simh@groups.io?subject=Re:%20Re%3A%20%5Bsimh%5D%20Old%20VAX%2FVMS%20Tapes>
> | Reply To Sender
> <clemc@ccc.com?subject=Private:%20Re:%20Re%3A%20%5Bsimh%5D%20Old%20VAX%2FVMS%20Tapes>
> | Mute This Topic <https://groups.io/mt/103433309/4811590> | New Topic
> <https://groups.io/g/simh/post>
> Your Subscription <https://groups.io/g/simh/editsub/4811590> | Contact
> Group Owner <simh+owner@groups.io> | Unsubscribe
> <https://groups.io/g/simh/leave/8620764/4811590/1680534689/xyzzy> [
> clemc@ccc.com]
> _._,_._,_
>
>

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