Pertec Tape Drive Interface Musings
dave.g4ugm at gmail.com
Wed Jun 10 11:45:26 CDT 2015
> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mark J.
> 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
> 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
> doesn't succeed.
> I particularly like the idea of being able to extract questionable data
> Ok, now three more questions come to mind:
> 1) Is it ever acceptable to mix densities on a single tape? I'm not sure
> 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
> 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
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
> 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>
More information about the cctech