9 track tapes and block sizes
dave.g4ugm at gmail.com
dave.g4ugm at gmail.com
Thu Sep 17 01:38:01 CDT 2020
> -----Original Message-----
> From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Dennis Boone via
> Sent: 17 September 2020 06:53
> To: cctalk at classiccmp.org
> Subject: Re: 9 track tapes and block sizes
> > What I know is that tape is subdivided in files by means of marks, >
> file is subdivided in blocks of equal size.
> Er, no. The blocks aren't necessarily of equal size. Unix people who are
> tar often seem to have this mindset, but the general case is that records
> of varying size.
On labelled tapes the blocks are almost certainly different sizes. Usually
one or more 80-charater labels followed by a tape mark followed by data
> > Now suppose you find and unknown tape you want to preserve: using dd >
> you could easily 1:1 copy tape files to hard disk files using a SCSI >
> DON'T DO THAT. If you use dd, you're throwing away information.
> Specifically, you're throwing away knowledge of the block size. Most of
> conventional unix utilities don't care. Many other things do. In many
> difficult or impossible to reconstruct the block sizes from the content,
> if it was, it's terrible archival practice.
> There are file formats for containing tape image data. The most common
> is probably the simh .tap format. These all preserve block lengths, tape
> indications of errors in reading the original, etc. Many fail to provide
> to embed metadata, but you can put that in separate adjacent files.
The docs for SIMH .TAP files are here:-
be careful as there are also non-SIMH .tap formats
In the IBM Mainframe emulation world there is also .AWS, an IBM format
introduced with its P390 Microchannel Mainframe card
and .HET a Hercules extension to .AWS which allows compression
note all the above formats contain info that allows the file to be read
block by block, both forwards and backwards, from any position on the tape.
> > But: how you know which block size is on the tape?
> Generally speaking, do a read of a blocksize as large or larger than the
> the tape, and the system will hand you the full record, and the actual
> of bytes read. If you're writing C or scripting code, the unix read()
> this. From the command line, you can do it with dd - specify a large
> and a count of 1, and it'll tell you what it actually got as it exits.
> For 9 track, few systems could write blocks larger than 32k or 64k, so
> decent guesses for "large" there. If it's DLT or something more modern,
> the largest possible block might be a lot larger. The system reading the
> may impose a limit based on available buffer space. You should able to
> iteratively determine the largest size it will accept.
Long block mean fewer inter-block gaps so are often a choice for archives,
especially on 6250BPI 9-track tape.
If you are lucky and the tape contains labels these usually have info about
the block and record size.
Of and yes tape data often has records embedded in the block without
terminating <lf> , <cr> or <crlf> characters.
So it was common to use tapes with 800 byte blocks, with 10 card images in
each block, or 1200 byte blocks with ten 120 byte printer lines in each
For commercial data you may even find multiple record types, so when I
worked in insurance, we would have a customer record with one or more policy
You will also find variable length records and blocks where there are length
fields in the blocks.
Of course that was a long time ago...
.. also on 9-track tapes its possible to read off the end of the tape.
> Many of the quarter-inch cartridge formats actually don't support block
> other than 512 bytes. If they were used on systems that expected to be
> write larger and/or variable records, the system hardware or software may
> have implemented a logical blocking layer on top of the
> 512 hardware layer. If you're reading one of these and don't have the
> hardware/software to decode it, you'll have to figure out how to decipher
Hope this helps
More information about the cctech