[Info-vax] Backup TK50 tapes

[glen herrmannsfeldt]

Paul Sture <nospam at sture.ch> wrote:
> In article <kgfcuq$9f1$1 at Iltempo.Update.UU.SE>,
> Johnny Billquist <bqt at softjar.se> wrote:
 
>> Actually, I think for most hardware, the limit is actually 64k 
>> for one read.

I have read/written 100K on unix 9track drives. 

The channel/controller that go with IBM mainframes can, I believe,
write up to 65535 bytes, but OS/360 used signed arithmetic so only
allowed 32767. 

As I understand it, though, with data chaining you can write (or read)
longer, up to a whole tape. With the assumption that the processor is
fast enough to keep up, data chaining allows more than one channel 
command (READ or WRITE) to apply to the same data block. It might fail
if other programs were limiting access to memory, though. 

For S/360 and I believe S/370, there was no block buffer between main
memory and the tape. (For systems with 64K of core, you might see why.)
(Actually, not for disk, either.) 

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

-- glen