10 Jun
2015
10 Jun
'15
9:45 a.m.
-----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/