> -----Original Message----- > From: cctalk [mailto:cctalk-boun...@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 <a...@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 <n...@nf6x.net> > http://www.nf6x.net/