Pertec Tape Drive Interface Musings

[Dave G4UGM]

> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mark J.
> Blair
> Sent: 10 June 2015 17:13
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: Pertec Tape Drive Interface Musings
> 
> 
> > On Jun 10, 2015, at 08:46, Al Kossow <aek at bitsavers.org> wrote:
> >
> > On 6/10/15 8:15 AM, Mark J. Blair wrote:
> >
> >> And that is precisely why I'm thinking of an ad-hoc interface rather
than
> just plugging a SCSI drive into a UNIX box.
> >
> > It also has the advantage that you can return the CRC/checksum and
> > partially read blocks. Most SCSI tape drives don't return the data if
the read
> doesn't succeed.
> 
> I particularly like the idea of being able to extract questionable data
and
> CRC/checksum.
> 
> Ok, now three more questions come to mind:
> 
> 1) Is it ever acceptable to mix densities on a single tape? I'm not sure
that my
> Kennedy drive will even allow that, but I don't know if that is universal.
> 

No idea. I suspect most drives will only change density at BOT

> 2) What's the scoop on a final record overlapping the EOT marker? Or even
a
> new record starting after the EOT marker? I seem to recall reading about
> some applications that stuck data after the EOT, such as backup volume
> information.

I seem to recall ALL applications put data after the EOT marker, should they
fill the tape. So on a write you get an EOT reached status, BUT to get this
you must have written past the EOT marker. If its non-labelled tape you
write a tape mark, rewind and unload the tape and ask for another.  It is up
to the application program to know there is more data. Typically on a
mainframe you wrote labelled tapes, so you needed to write a Tape Mark and
the End of Volume Label and any other labels needed, then another tape mark,
then unload and ask for the next reel. This usually goes after the EOT
marker. For labelled tapes the label tells you if there is another tape in
set.


> 
> 3) Did anybody ever go over to the dark side and implement copy protection
> on magtapes, say, by deliberately including a record with bad CRC that a
> normal driver+drive would not support writing? Or was that evil limited to
> the floppy disk world?


I don't believe you can do that. IBM Mainframe copy protection usually
involved using the serial number of the Mainframe. Total PITA when doing
Disaster recovery checks....

> 
> 
> --
> Mark J. Blair, NF6X <nf6x at nf6x.net>
> http://www.nf6x.net/