[Info-vax] Backup TK50 tapes

[Bob Koehler]

In article <kgghel$7fj$1 at speranza.aioe.org>, glen herrmannsfeldt <gah at ugcs.caltech.edu> writes:
> Paul Sture <nospam at sture.ch> wrote:
> 
> I have read/written 100K on unix 9track drives. 

   One 100K block?  Or a series of reads totaling 100K?

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