[Info-vax] Backup TK50 tapes

[glen herrmannsfeldt]

Bob Koehler <koehler at eisner.nospam.encompasserve.org> wrote:

(snip, I wrote)
>> I have read/written 100K on unix 9track drives. 
 
>   One 100K block?  Or a series of reads totaling 100K?

I haven't done it so recently, but I thought I remembered doing
it with either tar or dd. 

According to man st (SCSI tape) on my Linux system, earlier kernels
allow 128K on 32 bit systems and 256K on 64 bit systems, with a
buffer allocated as one block. Newer kernels can allocate the buffer
in up to 16 pieces, for 2M or 4M block size.
 
>> PL/I has LOCATE mode I/O, which allows for I/O without an intermediate
>> buffer. For read/write to/from a structure, the bytes are already in the
>> right order.
  
>>> I believe that is correct.  However I purposely restricted VMS backup 
>>> tapes to a maximum of 32K because that meant I could copy savesets to 
>>> disk.
 
>> Is that a VMS limit or DEC hardware limit?
 
>   I've seen tapes on VAX MASSBUS, UNIBUS, and Qbus drives, in each case
>   the controller having a 16 bit length register.  You just can't
>   go longer.  The controller then transfered the bytes at that length
>   to the drive as a single tape block.
 
>   I've worked with folks who had SEL 32, which could only do half of
>   this.
 
>>> Tapes with "infinite" block sizes do exist, for example for recording 
>>> seismological results and you need special hardware to read such tapes.
 
>> I remember reading about incremental tape drives that can write single
>> bytes and advance the tape appropriately. At least at the lower
>> densities that works. (For GCR you would at least need to buffer one
>> group.)
 
>   I worked with 14 and 48 track tapes that had no inter-record gap,
>   no record preamble, no record trailer, and no file marks.  They
>   were about 2 inches wide and 30 inches across.
 
>   We had them connected to VAXen via MASSBUS and custom controller 
>   hardware.  Couldn't get around MASSBUS transfer limits.  The VAX
>   had to keep up with a fairly constant data flow, no tape start/stop.
>   It was one of the places we took advantage of the VMS kernel's hard
>   real-time capability.  If we got behind for even one data transfer,
>   we failed.  That meant fielding the interrupt, starting the next DMA,
>   and doing I/O  post-processing, before some tiny FIFO overflowed 
>   (many milliseconds).  Not to mention the application had to keep enough 
>   outstanding I/O queued up, and do something with the data as it came 
>   in (output to a disk on a different MASSBUS using asynchronous $QIO 
>   disk file writes).
 
>   Thanks the VMS's kernel, we kept this running on 11/780 for the
>   entire length of tapes, most of an hour.  Worked for data transfers
>   from disk to such tapes, too.

For S/360, you can write larger blocks with data chaining. That is,
more than one CCW for the block. (Among others, it allows for
scatter/gather I/O operations.)  Also, as you say, the timing is
critical. CCWs have to be fetched from memory (self modifying 
channel programs, or system modifying while they are running,
are both allowed). So, the channel has to fetch the new CCW and
continue the operation while data transfer continues.

-- glen