29 Jul
2016
29 Jul
'16
11:08 a.m.
From: Mouse
they require that I subject myself to the Web.
I recognize that few people share this attitude.
Well, I sorta understand; the modern 'active content' mania causes me to
grind my teeth, too.
But the non-active Web has major benefits. E.g. I read this list via the
(entirely non-active :-) archive page, so my mailbox doesn't get cluttered up
with the dross.
Noel
29 Jul
29 Jul
12:07 p.m.
New subject: Question re Teac MT-2ST encoder roller tire
Recently acquired a Teac MT-2ST SCSI
cassette tape drive and am
attempting to recondition it.
Although it does have direct drive
motors on both reels (no rubber bands),
the design is still plagued by having a
rubber roller "tire" on its encoder
roller which has turned to a very sticky
goo for half its length on my unit.
Thankfully, Bitsavers not only has the
service manual for this unit, but
also photos! This photo shows the
encoder roller and tire:
http://bitsavers.trailing-edge.com/pdf/teac/MT-2ST/photos/2.JPG
The tire appears to be 1 cm wide, 1.5mm
thick, and ~1/4" tall (for
the 1/4" tape). The tire is inset into
the metal roller wheel.
Has anyone successfully attempted
replacing this tire, and if so, how
did you do it?
I've removed the tire -- half of which
was pure goo -- and am thinking
maybe to fill the tire inset void with
an elastomeric caulk, smoothing it
out to meet the outer edge of the rest
of the roller.
A really short rubber band about the
size of a pinky finger would work
nicely also.
Thank you-
-John
12:29 p.m.
New subject: Question re Teac MT-2ST encoder roller tire
On 07/29/2016 12:07 PM, js at cimmeri.com wrote:
Recently acquired a Teac MT-2ST SCSI cassette tape drive and am
attempting to recondition it.
Although it does have direct drive motors on both reels (no rubber
bands), the design is still plagued by having a rubber roller "tire"
on its encoder roller which has turned to a very sticky goo for half
its length on my unit.
Instead of fooling around with a baling-wire-and-bubblegum solution,
you're probably best off sending the roller for rebuilding by Terry:
http://www.terrysrubberrollers.com/
He does a bang-up job and he's not frighteningly expensive. You'll get
something back that will last for many years.
--Chuck
30 Jul
30 Jul
6:16 p.m.
New subject: Question re Teac MT-2ST encoder roller tire
On 7/29/2016 2:29 PM, Chuck Guzis wrote:
On 07/29/2016 12:07 PM, js at cimmeri.com wrote:
Thank you, Chuck. I'll give my idea a
try first, and then Terry's as a last
resort.
I'll report back here with results as
they occur.
- John
Recently acquired a Teac MT-2ST SCSI cassette
tape drive and am
attempting to recondition it.
Although it does have direct drive motors on both reels (no rubber
bands), the design is still plagued by having a rubber roller "tire"
on its encoder roller which has turned to a very sticky goo for half
its length on my unit.
Instead of fooling around with a baling-wire-and-bubblegum
solution,
you're probably best off sending the roller for rebuilding by Terry:
http://www.terrysrubberrollers.com/
He does a bang-up job and he's not frighteningly expensive. You'll get
something back that will last for many years.
--Chuck
17 Aug
17 Aug
11:07 a.m.
New subject: Are old SCSI tape drives not all created equal?
Hi, folks.
I'm experimenting with various old
SCSI tape drives to see which
will work with my PDP-11/34 with an
Emulex SCSI card.
To my surprise, not all SCSI tape
drives are created equal. I
was under the mistaken assumption that
all SCSI tape drives would
pretty much be abstracted the same way
by the SCSI interface.
Drives that are working fine are:
- Archive Python DAT
- Exabyte 8mm
- Cipher 995 9 track
- any of the DEC branded DLT drives
Drives that aren't recognized are:
- Teac MT-2ST (this drive seems
completely nonstandard -- can't
even use it as an ASPI
drive under MSDOS)
- OnStream Advanced Digital Recording
(ADR) SC-30 (doesn't
work under MSDOS /
ASPI either, but does work
under Windows 98(!)
with a special driver.
Won't work under WinXP
with same driver.
- Quantum branded DLT drives (work
fine under MSDOS / ASPI)
Question: So, even though some tape
drives physically have a SCSI
interface, are they different in some
other way such as to require
special software to use them? Or maybe
there were different
SCSI standards? Or is the standard
simply imperfect?
Any commentary, appreciated. Thank you.
- John
11:37 a.m.
New subject: Are old SCSI tape drives not all created equal?
To my surprise, not all SCSI tape drives are created
equal. I was
under the mistaken assumption that all SCSI tape drives would pretty
much be abstracted the same way by the SCSI interface.
That's the ideal. As you discovered, the world is far from ideal.
Question: So, even though some tape drives physically
have a SCSI
interface, are they different in some other way such as to require
special software to use them?
Probably. See below for a brief discussion of what "SCSI" is and how
it's relevant.
Or maybe there were different SCSI standards? Or is
the standard
simply imperfect?
I feel reasonably sure each of those holds part of the explanation.
Another issue, especially relevant on this list, is that some drives
date to before the standards were in their current form; they may
conform to early drafts, drafts which are incompatible with the spec we
know today. Other drives don't conform to any known document, whether
deliberately (customer lockin?) or not (sloppy firmware authors?).
So, yes, some drives - especially older ones - may need drive-specific
code.
SCSI is more than just the physical interface. Traditional SCSI is a
parallel interface, with a bunch of signals and grounds. But, layered
atop the physical interface, there is also a command/response protocol
which is, strictly, independent of the physical layer. (I have seen it
said that the SCSI protocol is very similar to both ATAPI and SAS,
probably because it influenced their design, though I haven't read
enough of any of them to really have a good handle on it myself.)
In particular, a drive may conform to the mechanical and electrical
interface but still be completely off the wall when it comes to the
command/resposne protocol. To pick a simple example, to read from a
tape[%], current SCSI sends a 0x08 command, which consists of one byte
of opcode, one byte of flag bits, three bytes of buffer length, and one
byte of control bits. There is no technical reason a drive maker
couldn't implement reads as a 0x72 opcode followed by two bytes of
buffer length and one byte of flag bits; it's not done because
customers would complain that it doesn't work with stock systems and
would switch to other makers which _do_ use the standard commands.
But, drives made before the spec was baked might use nonstandard
commands, especially for operations whose specs were in a state of flux
when the drive was designed. Look at NetBSD's st.c driver and search
for its quirk table and you can find a list of drives which are known
to need unusual interfacing in various ways. For example, a drive
identifying itself as "ARCHIVE " and "VIPER 2525 25462" apparently
needs to have a READ done in order to get good MODE SENSE data under at
least some circumstances (ST_Q_SENSE_HELP).
And, of course, some drives may want to support features for which
there is no standardized command.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
12:01 p.m.
New subject: Are old SCSI tape drives not all created equal?
On Wed, 17 Aug 2016, Mouse wrote:
SCSI is more than just the physical interface.
Traditional SCSI is a
parallel interface, with a bunch of signals and grounds. But, layered
atop the physical interface, there is also a command/response protocol
which is, strictly, independent of the physical layer. (I have seen it
said that the SCSI protocol is very similar to both ATAPI and SAS,
probably because it influenced their design, though I haven't read
enough of any of them to really have a good handle on it myself.)
I don't know of SAS offhand, however ATAPI is pretty much SCSI over ATA.
That is really SCSI commands and responses wrapped into the so called ATA
packets (hence the ATAPI acronym, standing for ATA Packet Interface) which
are chunks of data sent and retrieved with the ATA data write and read
commands. The USB storage protocol works similarly as well.
FWIW,
Maciej
12:09 p.m.
New subject: Are old SCSI tape drives not all created equal?
On Aug 17, 2016, at 3:01 PM, Maciej W. Rozycki
<macro at linux-mips.org> wrote:
On Wed, 17 Aug 2016, Mouse wrote:
Actually, SCSI is a distributed storage protocol, somewhat like an RPC. It is layered on
top of your choice of one of many possible transports; the original SCSI bus is one of
those. (The fact that both the protocol and that old bus are called "SCSI" is
an unfortunate source of confusion.)
Other transports include Fibre Channel, iSCSI, and SAS. In all cases, the packets going
back and forth are SCSI packets. Some addressing details change as you change transports,
but the basic I/O remains consistent. For example, if you read the iSCSI standard,
you'll find some target discovery machinery, session (communication channel)
establishment, etc. But the core of iSCSI is a set of packets for carrying SCSI packets,
and for the definition of what those packets look like and how they are used, you'd
read the SCSI standard, not the iSCSI one.
paul
SCSI is more than just the physical interface.
Traditional SCSI is a
parallel interface, with a bunch of signals and grounds. But, layered
atop the physical interface, there is also a command/response protocol
which is, strictly, independent of the physical layer. (I have seen it
said that the SCSI protocol is very similar to both ATAPI and SAS,
probably because it influenced their design, though I haven't read
enough of any of them to really have a good handle on it myself.)
I don't know of SAS offhand, however ATAPI is pretty much SCSI over ATA.
That is really SCSI commands and responses wrapped into the so called ATA
packets (hence the ATAPI acronym, standing for ATA Packet Interface) which
are chunks of data sent and retrieved with the ATA data write and read
commands. The USB storage protocol works similarly as well. 
12:11 p.m.
New subject: Are old SCSI tape drives not all created equal?
On Aug 17, 2016, at 12:01 PM, Maciej W. Rozycki
<macro at linux-mips.org> wrote:
On Wed, 17 Aug 2016, Mouse wrote:
If you *really* want to see how this was screwed up, take a look at
Fibre Channel (which is basically SCSI over an optical Fibre network).
While the commands are standard, you can?t really build a Fibre Channel
configuration without using (a lot) of vendor unique commands. And guess
what? Each vendor has their own set! It?s so bad that each combination
has to be tested (even down to the Fibre channel cards?the commands
they support are not all the same). In other words, just because I have a
working configuration with brand A card, brand C switch and brand E
disk array, does not mean that I can put in a brand B switch and still expect
it all to work. The sad thing is that the industry is/was happy with that.
TTFN - Guy
SCSI is more than just the physical interface.
Traditional SCSI is a
parallel interface, with a bunch of signals and grounds. But, layered
atop the physical interface, there is also a command/response protocol
which is, strictly, independent of the physical layer. (I have seen it
said that the SCSI protocol is very similar to both ATAPI and SAS,
probably because it influenced their design, though I haven't read
enough of any of them to really have a good handle on it myself.)
I don't know of SAS offhand, however ATAPI is pretty much SCSI over ATA.
That is really SCSI commands and responses wrapped into the so called ATA
packets (hence the ATAPI acronym, standing for ATA Packet Interface) which
are chunks of data sent and retrieved with the ATA data write and read
commands. The USB storage protocol works similarly as well.
12:18 p.m.
New subject: Are old SCSI tape drives not all created equal?
On Aug 17, 2016, at 3:11 PM, Guy Sotomayor Jr <ggs
at shiresoft.com> wrote:
...
If you *really* want to see how this was screwed up, take a look at
Fibre Channel (which is basically SCSI over an optical Fibre network).
While the commands are standard, you can?t really build a Fibre Channel
configuration without using (a lot) of vendor unique commands. And guess
what? Each vendor has their own set! It?s so bad that each combination
has to be tested (even down to the Fibre channel cards?the commands
they support are not all the same). In other words, just because I have a
working configuration with brand A card, brand C switch and brand E
disk array, does not mean that I can put in a brand B switch and still expect
it all to work. The sad thing is that the industry is/was happy with that.
But customers weren't, which is why iSCSI was so successful. It offers the same
capability but with a design goal of interoperability rather than the lack of it.
paul
12:31 p.m.
New subject: Are old SCSI tape drives not all created equal?
On Aug 17, 2016, at 12:18 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Yes, and most fibre channel companies (if they survived) have switched to iSCSI.
The other issue was that most folks that were doing fibre channel didn?t understand
networking *at all*. This was part of the problem. They were trying to ?invent? things
like routing and bridging without understanding that the problems were well understood
and for the most part solved?so they invented their own things that didn?t work
particularly well. Even when they did know about how networking protocols did things,
they decided to go their own way because they arrogantly believed that they knew
better and that storage was ?different?.
Have many scars from doing battle with them trying to get them to change their ways.
It was one of only two times in my career that I?ve actually regretted working for a
company and had no positive experiences.
TTFN - Guy
On Aug 17, 2016, at 3:11 PM, Guy Sotomayor Jr
<ggs at shiresoft.com> wrote:
...
If you *really* want to see how this was screwed up, take a look at
Fibre Channel (which is basically SCSI over an optical Fibre network).
While the commands are standard, you can?t really build a Fibre Channel
configuration without using (a lot) of vendor unique commands. And guess
what? Each vendor has their own set! It?s so bad that each combination
has to be tested (even down to the Fibre channel cards?the commands
they support are not all the same). In other words, just because I have a
working configuration with brand A card, brand C switch and brand E
disk array, does not mean that I can put in a brand B switch and still expect
it all to work. The sad thing is that the industry is/was happy with that.
But customers weren't, which is why iSCSI was so successful. It offers the same
capability but with a design goal of interoperability rather than the lack of it. 
12:45 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 2016-08-17 4:11 PM, Guy Sotomayor Jr wrote:
No fSCSI is SCSI over fibre transport layer just like iSCSI is SCSI
encapsulated in IP packets. Fibre channel protocol is just a
transport layer just like ethernet. You can put whatever you like
into the fibre channel packets, most commonly it happens to be SCSI but
it is also pretty common to IP over fibre. Likewise you can put
whatever you want into an ethernet packet, most commonly it is IP but
FCOE is fibre channel protocol over Ethernet transport layer, and then
on top of FCOE you would run fSCSI.
SAS is another serial SCSI protocol as was IBM's SSA and for the most
part Apple's firewire.
Paul.
On Aug 17,
2016, at 12:01 PM, Maciej W. Rozycki <macro at linux-mips.org> wrote:
On Wed, 17 Aug 2016, Mouse wrote:
If you *really* want to see how this was screwed up, take a look at
Fibre Channel (which is basically SCSI over an optical Fibre network).
While the commands are standard, you can?t really build a Fibre Channel
configuration without using (a lot) of vendor unique commands. And guess
what? Each vendor has their own set! It?s so bad that each combination
has to be tested (even down to the Fibre channel cards?the commands
they support are not all the same). In other words, just because I have a
working configuration with brand A card, brand C switch and brand E
disk array, does not mean that I can put in a brand B switch and still expect
it all to work. The sad thing is that the industry is/was happy with that.
TTFN - Guy
SCSI is more than just the physical interface.
Traditional SCSI is a
parallel interface, with a bunch of signals and grounds. But, layered
atop the physical interface, there is also a command/response protocol
which is, strictly, independent of the physical layer. (I have seen it
said that the SCSI protocol is very similar to both ATAPI and SAS,
probably because it influenced their design, though I haven't read
enough of any of them to really have a good handle on it myself.)
I don't know
of SAS offhand, however ATAPI is pretty much SCSI over ATA.
That is really SCSI commands and responses wrapped into the so called ATA
packets (hence the ATAPI acronym, standing for ATA Packet Interface) which
are chunks of data sent and retrieved with the ATA data write and read
commands. The USB storage protocol works similarly as well.
12:29 p.m.
New subject: Are old SCSI tape drives not all created equal?
Thanks very much, Mouse, Paul, Maciej,
and Guy for helping me
understand my SCSI tape drives. I had
no idea!
- John
11:46 a.m.
New subject: Are old SCSI tape drives not all created equal?
On Aug 17, 2016, at 2:07 PM, js at cimmeri.com wrote:
...
Or maybe there were different
SCSI standards? Or is the standard simply imperfect?
Yes.
Among other things, SCSI is very peculiar in that it sends out many "draft"
standards but allows devices to be built that "conform" to those drafts.
Contrast that with the much better IETF practice, where drafts are intended only for
standards development, and "conforms" is a term that can only be used with
official standards (RFCs).
paul
12:38 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/17/2016 11:07 AM, js at cimmeri.com wrote:
I'm experimenting with various old SCSI tape
drives to see which will
work with my PDP-11/34 with an Emulex SCSI card.
To my surprise, not all SCSI tape drives are created equal. I was
under the mistaken assumption that all SCSI tape drives would pretty
much be abstracted the same way by the SCSI interface.
Well, let's get to the nub of things--exactly what commands aren't
supported in each particular drive? At a minimum, they should all
provide a response to an "IDENTIFY" command.
6-byte CDBs for read and write are probably supported across all drives
as well, though there are some cases of special "flags".
REWIND should be supported and possibly SPACE commands. After that,
it's a craps shoot. Not everyone adhered to the ANSI spec.
Back when I was writing forensic tools, I had to deal with a wide range
of SCSI drives. I quickly learned to pare my command set down to a
minimum and how to deal gracefully with unsupported features.
Andy Johnson-Laird used to refer to "SCSI Voodoo" and he wasn't far off
the mark.
--Chuck
2:59 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 8/17/2016 2:38 PM, Chuck Guzis wrote:
On 08/17/2016 11:07 AM, js at cimmeri.com wrote:
Hi, Chuck. Excellent question -- and they do respond per your minimum, but beyond that,
I'm not sure. When a drive wouldn't work, I only thought to check for unit ready,
unit identify, and to see what would happen with a START or STOP unit command.
Even the Teac MT-2ST would respond to those 3 (for the START or STOP command, it
retensions the entire tape). Interestingly, the Teac also doesn't provide a unit
name like all the others do eg. "ARCHIVE PYTHON etc..." It just shows up as a
blank during bootup on a PC with an Adaptec SCSI card. This lack of name seems to make it
invisible to Windows (XP) ASPI.
I have MSDOS software than allows one to issue direct SCSI commands, but doing that is
beyond my present know-how.
Thank you-
-John
I'm experimenting with various old SCSI tape
drives to see which will
work with my PDP-11/34 with an Emulex SCSI card.
To my surprise, not all SCSI tape drives are created equal. I was
under the mistaken assumption that all SCSI tape drives would pretty
much be abstracted the same way by the SCSI interface.
Well, let's get to the
nub of things--exactly what commands aren't
supported in each particular drive? At a minimum, they should all
provide a response to an "IDENTIFY" command. 6-byte CDBs for read and write are probably supported
across all drives
as well, though there are some cases of special "flags".
REWIND should be supported and possibly SPACE commands. After that,
it's a craps shoot. Not everyone adhered to the ANSI spec.
Back when I was writing forensic tools, I had to deal with a wide range
of SCSI drives. I quickly learned to pare my command set down to a
minimum and how to deal gracefully with unsupported features.
Andy Johnson-Laird used to refer to "SCSI Voodoo" and he wasn't far off
the mark.
--Chuck
3:42 p.m.
New subject: Are old SCSI tape drives not all created equal?
On Wed, 2016-08-17 at 16:59 -0500, js at cimmeri.com wrote:
Hi, Chuck. Excellent question -- and they do respond
per your minimum, but beyond that, I'm not sure.
What device type do they report to IDENTIFY? There were some early tape
drives which presented as direct-access (not sequential-access, which
was more conventional for tape drives) and could be used as though they
were extremely slow hard disks.
p.
4:17 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/17/2016 02:59 PM, js at cimmeri.com wrote:
Hi, Chuck. Excellent question -- and they do respond
per your
minimum, but beyond that, I'm not sure. When a drive wouldn't work,
I only thought to check for unit ready, unit identify, and to see
what would happen with a START or STOP unit command.
Even the Teac MT-2ST would respond to those 3 (for the START or STOP
command, it retensions the entire tape). Interestingly, the Teac
also doesn't provide a unit name like all the others do eg. "ARCHIVE
PYTHON etc..." It just shows up as a blank during bootup on a PC
with an Adaptec SCSI card. This lack of name seems to make it
invisible to Windows (XP) ASPI.
I have MSDOS software than allows one to issue direct SCSI commands,
but doing that is beyond my present know-how.
Well, that's all good. SCSI tape covers a lot of ground--from 9 track
1/2" open-reel drives and includes various technologies, from simple
DCxxx QIC carts, to DDS, SLT, DLT... All have their peculiarities.
For example, some permit rewriting of blocks; others put this strictly
off-limits. Lots of features are vendor-optional, which include things
such as partitioned data sets and robot auto-loaders. Read-after-write
verification is optional (but is a good thing, particularly if the drive
firmware includes recovery by erase-and-rewrite.
Linux can be pretty decent about a one-size fits all and has several
optional packages that people have submitted, including the st toolkit.
If you can program C, I might have some DOS I/O library functions that
may interest you.
Generally speaking, the "safe, always there" commands are INQUIRY
(0x12), TEST UNIT READY (0x00), REWIND (0x01), REQUEST SENSE (0x03),
READ(6) (0x08), WRITE(6) (0x0a) WRITE FILEMARKS (0x10), MODE SENSE
(0x1a), MODE SELECT (0x15), UNLOAD (0x1b) and perhaps SPACE (0x11).
Of course, commands such as MODE SENSE, MODE SELECT and REQUEST SENSE
have variable implementations. Status for a given condition isn't
guaranteed to be the same across devices; for instance on the Qualstar
SCSI half-inch drives like to return a record of zero length instead of
setting the "filemark hit" status on a read operation.
Generally speaking, however, as long as you stick to the above list and
the simplest options, you'll be good with anything.
--Chuck
19 Aug
19 Aug
9:24 a.m.
New subject: Are old SCSI tape drives not all created equal?
On 8/17/2016 6:17 PM, Chuck Guzis wrote:
On 08/17/2016 02:59 PM, js at cimmeri.com wrote:
Chuck,
Where might I find information on how to form SCSI command data blocks so as to try the
above commands? I sent just an "01" to the TEAC MT-2ST, and it did rewind..
but did not react to any of the other above commands just by sending single bytes.
Oddly, the OnStream drive did *not* accept an 01 command.
Thank you-
-John
Hi, Chuck. Excellent question -- and they do
respond per your
minimum, but beyond that, I'm not sure. When a drive wouldn't work,
I only thought to check for unit ready, unit identify, and to see
what would happen with a START or STOP unit command.
Even the Teac MT-2ST would respond to those 3 (for the START or STOP
command, it retensions the entire tape). Interestingly, the Teac
also doesn't provide a unit name like all the others do eg. "ARCHIVE
PYTHON etc..." It just shows up as a blank during bootup on a PC
with an Adaptec SCSI card. This lack of name seems to make it
invisible to Windows (XP) ASPI.
I have MSDOS software than allows one to issue direct SCSI commands,
but doing that is beyond my present know-how.
Well, that's all good. SCSI
tape covers a lot of ground--from 9 track
1/2" open-reel drives and includes various technologies, from simple
DCxxx QIC carts, to DDS, SLT, DLT... All have their peculiarities.
For example, some permit rewriting of blocks; others put this strictly
off-limits. Lots of features are vendor-optional, which include things
such as partitioned data sets and robot auto-loaders. Read-after-write
verification is optional (but is a good thing, particularly if the drive
firmware includes recovery by erase-and-rewrite.
Linux can be pretty decent about a one-size fits all and has several
optional packages that people have submitted, including the st toolkit.
If you can program C, I might have some DOS I/O library functions that
may interest you.
Generally speaking, the "safe, always there" commands are INQUIRY
(0x12), TEST UNIT READY (0x00), REWIND (0x01), REQUEST SENSE (0x03),
READ(6) (0x08), WRITE(6) (0x0a) WRITE FILEMARKS (0x10), MODE SENSE
(0x1a), MODE SELECT (0x15), UNLOAD (0x1b) and perhaps SPACE (0x11). Of course, commands such as MODE SENSE, MODE SELECT
and REQUEST SENSE
have variable implementations. Status for a given condition isn't
guaranteed to be the same across devices; for instance on the Qualstar
SCSI half-inch drives like to return a record of zero length instead of
setting the "filemark hit" status on a read operation.
Generally speaking, however, as long as you stick to the above list and
the simplest options, you'll be good with anything.
--Chuck
10:36 a.m.
New subject: Are old SCSI tape drives not all created equal?
On 8/19/2016 9:24 AM, js at cimmeri.com wrote:
On 8/17/2016 6:17 PM, Chuck Guzis wrote:
Try sending 0x01 followed by 5 or 7 0x00's before dropping select. i
don't think the Teac should have responded to a single byte after select
then drop select. Commands are packets of either 6 or 8 bytes, and
other should be avoided, unless the vendor documents an exception.
Select with attention which is a reconnect could send shorter packets
for status and the like, but not a command.
On 08/17/2016 02:59 PM, js at cimmeri.com wrote:
Chuck,
Where might I find information on how to form SCSI command data
blocks so as to try the above commands? I sent just an "01" to the
TEAC MT-2ST, and it did rewind.. but did not react to any of the other
above commands just by sending single bytes.
Oddly, the OnStream drive did *not* accept an 01 command.
Hi, Chuck. Excellent question -- and they do
respond per your
minimum, but beyond that, I'm not sure. When a drive wouldn't work,
I only thought to check for unit ready, unit identify, and to see
what would happen with a START or STOP unit command.
Even the Teac MT-2ST would respond to those 3 (for the START or STOP
command, it retensions the entire tape). Interestingly, the Teac
also doesn't provide a unit name like all the others do eg. "ARCHIVE
PYTHON etc..." It just shows up as a blank during bootup on a PC
with an Adaptec SCSI card. This lack of name seems to make it
invisible to Windows (XP) ASPI.
I have MSDOS software than allows one to issue direct SCSI commands,
but doing that is beyond my present know-how.
Well, that's all good. SCSI
tape covers a lot of ground--from 9 track
1/2" open-reel drives and includes various technologies, from simple
DCxxx QIC carts, to DDS, SLT, DLT... All have their peculiarities.
For example, some permit rewriting of blocks; others put this strictly
off-limits. Lots of features are vendor-optional, which include things
such as partitioned data sets and robot auto-loaders. Read-after-write
verification is optional (but is a good thing, particularly if the drive
firmware includes recovery by erase-and-rewrite.
Linux can be pretty decent about a one-size fits all and has several
optional packages that people have submitted, including the st toolkit.
If you can program C, I might have some DOS I/O library functions that
may interest you.
Generally speaking, the "safe, always there" commands are INQUIRY
(0x12), TEST UNIT READY (0x00), REWIND (0x01), REQUEST SENSE (0x03),
READ(6) (0x08), WRITE(6) (0x0a) WRITE FILEMARKS (0x10), MODE SENSE
(0x1a), MODE SELECT (0x15), UNLOAD (0x1b) and perhaps SPACE (0x11). Thank you-
-John
Of course, commands such as MODE SENSE, MODE
SELECT and REQUEST SENSE
have variable implementations. Status for a given condition isn't
guaranteed to be the same across devices; for instance on the Qualstar
SCSI half-inch drives like to return a record of zero length instead of
setting the "filemark hit" status on a read operation.
Generally speaking, however, as long as you stick to the above list and
the simplest options, you'll be good with anything.
--Chuck
11:08 a.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/19/2016 09:24 AM, js at cimmeri.com wrote:
Where might I find information on how to form SCSI
command data
blocks so as to try the above commands? I sent just an "01" to the
TEAC MT-2ST, and it did rewind.. but did not react to any of the
other above commands just by sending single bytes.
Oddly, the OnStream drive did *not* accept an 01 command.
Thank you- -John
John, what's your working OS platform? For fooling with SCSI, the ASPI
interface of MS-DOS is pretty straightforward--and easy to use.
http://ftp.isu.edu.tw/pub/Hardware/ADAPTEC/adaptec/aspi_dos.txt
..and if you goof up, just hit the RESET button and you're back in
business in a few seconds.
A CDB's a CDB, so whatever you learn on DOS can easily be transfered to
other OS interfaces (SPTI, SG, CAM, etc.).
As far as tape-drive specific commands, there's always an ANSI T10
document, but that's like trying to learn about parking regulations from
a university law library--it's probably all there, but you'll have to
plow your way through a lot of stuff. FWIW, T10 doesn't refer to the
things as "tape drives", but "sequential access devices". Here's
a T10
draft:
http://hackipedia.org/Hardware/SCSI/Stream%20Commands/SCSI-3%20Stream%20Com…
By far and away, the best place to learn practical SCSI interfacing is
from vendor's manuals themselves. One I found
particularly useful was
the HP 35470 DDS drive OEM product manual. Very clear
writing style.
Bitsavers is full of product manuals detailing exactly what and how a
product supports.
--Chuck
11:18 a.m.
New subject: Are old SCSI tape drives not all created equal?
apparently it isn't SCSI
http://oldcomputer.info/media/teac/index.htm
On 8/19/16 11:08 AM, Chuck Guzis wrote:
On 08/19/2016 09:24 AM, js at cimmeri.com wrote:
> Where might I find information on how to form SCSI command data
> blocks so as to try the above commands? I sent just an "01" to the
> TEAC MT-2ST, and it did rewind.. but did not react to any of the
> other above commands just by sending single bytes.
>
12:16 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/19/2016 11:18 AM, Al Kossow wrote:
apparently it isn't SCSI
http://oldcomputer.info/media/teac/index.htm
But the product spec about says (top of PDF page 6):
Interface: In compliance with SCSI ANSI X3.131-1986
..and the remainder of the document certainly would seem to imply SCSI,
right down to the "SCSI ID" selections.
--Chuck
1:28 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 8/19/2016 2:16 PM, Chuck Guzis wrote:
On 08/19/2016 11:18 AM, Al Kossow wrote:
There were 2-3 versions. One was SCSI,
the next QIC-02, and the last, some raw
interface called "BASIC." I've both a
SCSI and a QIC-02 version.
- John
apparently it isn't SCSI
http://oldcomputer.info/media/teac/index.htm
But the product spec about says (top
of PDF page 6):
Interface: In compliance with SCSI ANSI X3.131-1986
..and the remainder of the document certainly would seem to imply SCSI,
right down to the "SCSI ID" selections.
--Chuck
2:14 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/19/2016 01:28 PM, js at cimmeri.com wrote:
There were 2-3 versions. One was SCSI, the next
QIC-02, and the
last, some raw interface called "BASIC." I've both a SCSI and a
QIC-02 version.
That figures--they did a similar thing with the floppy drives--the Teac
SCSI floppy is little more than a standard floppy with a SCSI controller
board bolted on.
Just going by Al's document.
I wonder if the "BASIC" interface is a simple QIC-36.
--Chuck
1:41 p.m.
New subject: Are old SCSI tape drives not all created equal?
Al, you don't happen to have this
anywhere, do you?
"Small Computer System Interface: An
Overview and a Developer's Guide"
Company: Digital Equipment Corporation
Part: EK-SCSIS-DK
-John
On 8/19/2016 1:18 PM, Al Kossow wrote:
apparently it isn't SCSI
http://oldcomputer.info/media/teac/index.htm
On 8/19/16 11:08 AM, Chuck Guzis wrote:
On 08/19/2016 09:24 AM, js at cimmeri.com wrote:
> Where might I find information on how to form SCSI command data
> blocks so as to try the above commands? I sent just an "01" to the
> TEAC MT-2ST, and it did rewind.. but did not react to any of the
> other above commands just by sending single bytes.
>
21 Aug
21 Aug
10:12 a.m.
New subject: Are old SCSI tape drives not all created equal?
On 8/19/2016 1:08 PM, Chuck Guzis wrote:
On 08/19/2016 09:24 AM, js at cimmeri.com wrote:
Chuck, for the purposes of testing the Teac drive, I'm using MSDOS on a 486 PC
platform with an Adaptec SCSI interface.
Where might I find information on how to form
SCSI command data
blocks so as to try the above commands? I sent just an "01" to the
TEAC MT-2ST, and it did rewind..
John, what's your working OS platform? For
fooling with SCSI, the ASPI
interface of MS-DOS is pretty straightforward--and easy to use.
http://ftp.isu.edu.tw/pub/Hardware/ADAPTEC/adaptec/aspi_dos.txt
..and if you goof up, just hit the RESET button and you're back in
business in a few seconds.
A CDB's a CDB, so whatever you learn on DOS can easily be transfered to
other OS interfaces (SPTI, SG, CAM, etc.).
As far as tape-drive specific commands, there's always an ANSI T10
document, but that's like trying to learn about parking regulations from
a university law library--it's probably all there, but you'll have to
plow your way through a lot of stuff. FWIW, T10 doesn't refer to the
things as "tape drives", but "sequential access devices". Here's
a T10
draft:
http://hackipedia.org/Hardware/SCSI/Stream%20Commands/SCSI-3%20Stream%20Com…
By far and away, the best place to learn practical SCSI interfacing is
from vendor's manuals themselves. One I found particularly useful was
the HP 35470 DDS drive OEM product manual. Very clear writing style.
Bitsavers is full of product manuals detailing exactly what and how a
product supports.
Thanks very much for providing these resource links.
So to recap what it is I *was* trying to do, and am *now* trying to do,
for any readers that are still curious about this:
I was going through various tape drives to see which would be compat with
an Emulux UC07 SCSI interface on a PDP-11/34 and also a Microvax III with
a CMD SCSI interface.
A good -- but not guaranteed -- predictor of which drives would work, is
to first see how well the tape drive will talk to Bart Lagerweij's
SCSI Tool Utility (an MSDOS program) with the drive connected to a PC.
I ran into problems with two drives: an OnStream ADR SC-30 and a Teac
MT-2ST 60MB drive. I was most hoping the Teac would work as it's a
pretty cool little device, and is closest in vintage to the 11/34
of all my tape drives except for a DEC TS05 and TSZ07.
Unfortunately, I could only get the OnStream the work connected to a
Windows machine -- with the right driver. Only with the right driver,
will it work with NT Backup or other software.
The Teac isn't working anywhere yet, although the drive appears to
be functional and is responding to a few primitives.
Neither of these two drives is going to work with the 11/34, so that
matter is closed.
The final matter is that I'd still like to get the Teac to function
with some software, just to watch it operate (you have to really like
mechanical things to understand this strange fascination). Having put
some time and $ into the Teac, it'd be nice to get some reward, even
if only then it gets placed on the shelf afterwards.
- John
10:34 a.m.
New subject: Are old SCSI tape drives not all created equal?
What are you using to send/receive the commands?
m
----- Original Message -----
From: <js at cimmeri.com>
To: <General at classiccmp.org>; "Discussion at classiccmp.org:On-Topic and
Off-Topic Posts" <cctalk at classiccmp.org>
Sent: Sunday, August 21, 2016 1:12 PM
Subject: Re: Are old SCSI tape drives not all created equal?
On 8/19/2016 1:08 PM, Chuck Guzis wrote:
On 08/19/2016 09:24 AM, js at cimmeri.com wrote:
Chuck, for the purposes of testing the Teac drive, I'm using MSDOS on a 486 PC
platform with an Adaptec SCSI interface.
Where might I find information on how to form
SCSI command data
blocks so as to try the above commands? I sent just an "01" to the
TEAC MT-2ST, and it did rewind..
John, what's your working OS platform? For
fooling with SCSI, the ASPI
interface of MS-DOS is pretty straightforward--and easy to use.
http://ftp.isu.edu.tw/pub/Hardware/ADAPTEC/adaptec/aspi_dos.txt
..and if you goof up, just hit the RESET button and you're back in
business in a few seconds.
A CDB's a CDB, so whatever you learn on DOS can easily be transfered to
other OS interfaces (SPTI, SG, CAM, etc.).
As far as tape-drive specific commands, there's always an ANSI T10
document, but that's like trying to learn about parking regulations from
a university law library--it's probably all there, but you'll have to
plow your way through a lot of stuff. FWIW, T10 doesn't refer to the
things as "tape drives", but "sequential access devices". Here's
a T10
draft:
http://hackipedia.org/Hardware/SCSI/Stream%20Commands/SCSI-3%20Stream%20Com…
By far and away, the best place to learn practical SCSI interfacing is
from vendor's manuals themselves. One I found particularly useful was
the HP 35470 DDS drive OEM product manual. Very clear writing style.
Bitsavers is full of product manuals detailing exactly what and how a
product supports.
Thanks very much for providing these resource links.
So to recap what it is I *was* trying to do, and am *now* trying to do,
for any readers that are still curious about this:
I was going through various tape drives to see which would be compat with
an Emulux UC07 SCSI interface on a PDP-11/34 and also a Microvax III with
a CMD SCSI interface.
A good -- but not guaranteed -- predictor of which drives would work, is
to first see how well the tape drive will talk to Bart Lagerweij's
SCSI Tool Utility (an MSDOS program) with the drive connected to a PC.
I ran into problems with two drives: an OnStream ADR SC-30 and a Teac
MT-2ST 60MB drive. I was most hoping the Teac would work as it's a
pretty cool little device, and is closest in vintage to the 11/34
of all my tape drives except for a DEC TS05 and TSZ07.
Unfortunately, I could only get the OnStream the work connected to a
Windows machine -- with the right driver. Only with the right driver,
will it work with NT Backup or other software.
The Teac isn't working anywhere yet, although the drive appears to
be functional and is responding to a few primitives.
Neither of these two drives is going to work with the 11/34, so that
matter is closed.
The final matter is that I'd still like to get the Teac to function
with some software, just to watch it operate (you have to really like
mechanical things to understand this strange fascination). Having put
some time and $ into the Teac, it'd be nice to get some reward, even
if only then it gets placed on the shelf afterwards.
- John
1:04 p.m.
New subject: Are old SCSI tape drives not all created equal?
Hi, Mike. See further below where I mention Bart Lagerweij's
SCSI Tool Utility (an MSDOS program) with the drive connected
to a PC.
- John
On 8/21/2016 12:34 PM, Mike Stein wrote:
What are you using to send/receive the commands?
m
----- Original Message -----
From:<js at cimmeri.com>
To:<General at classiccmp.org>; "Discussion at classiccmp.org:On-Topic and
Off-Topic Posts"<cctalk at classiccmp.org>
Sent: Sunday, August 21, 2016 1:12 PM
Subject: Re: Are old SCSI tape drives not all created equal?
On 8/19/2016 1:08 PM, Chuck Guzis wrote:
On 08/19/2016 09:24 AM, js at cimmeri.com wrote:
Chuck, for the
purposes of testing the Teac drive, I'm using MSDOS on a 486 PC platform with an
Adaptec SCSI interface.
Where might I find information on how to form
SCSI command data
blocks so as to try the above commands? I sent just an "01" to the
TEAC MT-2ST, and it did rewind..
John, what's your working OS platform? For
fooling with SCSI, the ASPI
interface of MS-DOS is pretty straightforward--and easy to use.
http://ftp.isu.edu.tw/pub/Hardware/ADAPTEC/adaptec/aspi_dos.txt
..and if you goof up, just hit the RESET button and you're back in
business in a few seconds.
A CDB's a CDB, so whatever you learn on DOS can easily be transfered to
other OS interfaces (SPTI, SG, CAM, etc.).
As far as tape-drive specific commands, there's always an ANSI T10
document, but that's like trying to learn about parking regulations from
a university law library--it's probably all there, but you'll have to
plow your way through a lot of stuff. FWIW, T10 doesn't refer to the
things as "tape drives", but "sequential access devices". Here's
a T10
draft:
http://hackipedia.org/Hardware/SCSI/Stream%20Commands/SCSI-3%20Stream%20Com…
By far and away, the best place to learn practical SCSI interfacing is
from vendor's manuals themselves. One I found particularly useful was
the HP 35470 DDS drive OEM product manual. Very clear writing style.
Bitsavers is full of product manuals detailing exactly what and how a
product supports.
Thanks very much for providing these resource links.
So to recap what it is I *was* trying to do, and am *now* trying to do,
for any readers that are still curious about this:
I was going through various tape drives to see which would be compat with
an Emulux UC07 SCSI interface on a PDP-11/34 and also a Microvax III with
a CMD SCSI interface.
A good -- but not guaranteed -- predictor of which drives would work, is
to first see how well the tape drive will talk to Bart Lagerweij's
SCSI Tool Utility (an MSDOS program) with the drive connected to a PC.
I ran into problems with two drives: an OnStream ADR SC-30 and a Teac
MT-2ST 60MB drive. I was most hoping the Teac would work as it's a
pretty cool little device, and is closest in vintage to the 11/34
of all my tape drives except for a DEC TS05 and TSZ07.
Unfortunately, I could only get the OnStream the work connected to a
Windows machine -- with the right driver. Only with the right driver,
will it work with NT Backup or other software.
The Teac isn't working anywhere yet, although the drive appears to
be functional and is responding to a few primitives.
Neither of these two drives is going to work with the 11/34, so that
matter is closed.
The final matter is that I'd still like to get the Teac to function
with some software, just to watch it operate (you have to really like
mechanical things to understand this strange fascination). Having put
some time and $ into the Teac, it'd be nice to get some reward, even
if only then it gets placed on the shelf afterwards.
- John
4:37 p.m.
New subject: Are old SCSI tape drives not all created equal?
----- Original Message -----
From: <js at cimmeri.com>
To: <General at classiccmp.org>; "Discussion at classiccmp.org:On-Topic and
Off-Topic Posts" <cctalk at classiccmp.org>
Sent: Sunday, August 21, 2016 4:04 PM
Subject: Re: Are old SCSI tape drives not all created equal?
Hi, Mike. See further below where I mention Bart Lagerweij's
SCSI Tool Utility (an MSDOS program) with the drive connected
to a PC.
- John
---------------------------
Thanks very much, John; missed it first time around.
I've got a pile of SCSI tape & disk drives that I'd like to sort through one
day; sounds like this'll at least give me a basic dead/alive indication.
m
On 8/21/2016 12:34 PM, Mike Stein wrote:
> What are you using to send/receive the commands?
>
> m
>
>
> ----- Original Message -----
> From:<js at cimmeri.com>
> To:<General at classiccmp.org>; "Discussion at classiccmp.org:On-Topic and
Off-Topic Posts"<cctalk at classiccmp.org>
> Sent: Sunday, August 21, 2016 1:12 PM
> Subject: Re: Are old SCSI tape drives not all created equal?
>
>
>>
>> On 8/19/2016 1:08 PM, Chuck Guzis wrote:
>>> On 08/19/2016 09:24 AM, js at cimmeri.com wrote:
>>>
>>>> Where might I find information on how to form SCSI command data
>>>> blocks so as to try the above commands? I sent just an "01"
to the
>>>> TEAC MT-2ST, and it did rewind..
>>> John, what's your working OS platform? For fooling with SCSI, the ASPI
>>> interface of MS-DOS is pretty straightforward--and easy to use.
>> Chuck, for the purposes of testing the Teac drive, I'm using MSDOS on a 486
PC platform with an Adaptec SCSI interface.
>>
>>
>>
>>> http://ftp.isu.edu.tw/pub/Hardware/ADAPTEC/adaptec/aspi_dos.txt
>>>
>>> ..and if you goof up, just hit the RESET button and you're back in
>>> business in a few seconds.
>>>
>>> A CDB's a CDB, so whatever you learn on DOS can easily be transfered to
>>> other OS interfaces (SPTI, SG, CAM, etc.).
>>>
>>> As far as tape-drive specific commands, there's always an ANSI T10
>>> document, but that's like trying to learn about parking regulations from
>>> a university law library--it's probably all there, but you'll have
to
>>> plow your way through a lot of stuff. FWIW, T10 doesn't refer to the
>>> things as "tape drives", but "sequential access devices".
Here's a T10
>>> draft:
>>>
>>>
http://hackipedia.org/Hardware/SCSI/Stream%20Commands/SCSI-3%20Stream%20Com…
>>>
>>> By far and away, the best place to learn practical SCSI interfacing is
>>> from vendor's manuals themselves. One I found particularly useful was
>>> the HP 35470 DDS drive OEM product manual. Very clear writing style.
>>>
>>> Bitsavers is full of product manuals detailing exactly what and how a
>>> product supports.
>> Thanks very much for providing these resource links.
>>
>>
>> So to recap what it is I *was* trying to do, and am *now* trying to do,
>> for any readers that are still curious about this:
>>
>> I was going through various tape drives to see which would be compat with
>> an Emulux UC07 SCSI interface on a PDP-11/34 and also a Microvax III with
>> a CMD SCSI interface.
>>
>> A good -- but not guaranteed -- predictor of which drives would work, is
>> to first see how well the tape drive will talk to Bart Lagerweij's
>> SCSI Tool Utility (an MSDOS program) with the drive connected to a PC.
>>
>> I ran into problems with two drives: an OnStream ADR SC-30 and a Teac
>> MT-2ST 60MB drive. I was most hoping the Teac would work as it's a
>> pretty cool little device, and is closest in vintage to the 11/34
>> of all my tape drives except for a DEC TS05 and TSZ07.
>>
>>
>> Unfortunately, I could only get the OnStream the work connected to a
>> Windows machine -- with the right driver. Only with the right driver,
>> will it work with NT Backup or other software.
>>
>> The Teac isn't working anywhere yet, although the drive appears to
>> be functional and is responding to a few primitives.
>>
>> Neither of these two drives is going to work with the 11/34, so that
>> matter is closed.
>>
>>
>> The final matter is that I'd still like to get the Teac to function
>> with some software, just to watch it operate (you have to really like
>> mechanical things to understand this strange fascination). Having put
>> some time and $ into the Teac, it'd be nice to get some reward, even
>> if only then it gets placed on the shelf afterwards.
>>
>>
>> - John
>>
>>
>>
>>
>>
>
10:46 a.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/21/2016 10:12 AM, js at cimmeri.com wrote:
The final matter is that I'd still like to get the
Teac to function
with some software, just to watch it operate (you have to really
like mechanical things to understand this strange fascination).
Having put some time and $ into the Teac, it'd be nice to get some
reward, even if only then it gets placed on the shelf afterwards.
Back in the day, I wondered if the DDS drives being as complex as they
were, with the skinny less-than-4mm wide tape could even have the
possibility of any longevity.
But the old DDS-1 tapes I recorded more than 20 years ago are still
quite readable as are the DDS-4 tapes I wrote over a decade ago. One
advantage that DDS (and DLT...) has over most of the "QIC" tapes is that
they use a read-after-write system like the big 1/2" tape drives, making
a separate verification pass unnecessary. They also tend to follow the
ANSI sequantial-access SCSI standard more carefully.
You may want to consider DDS or DLT for your DEC gear.
--Chuck
11:31 a.m.
New subject: Are old SCSI tape drives not all created equal?
On Aug 21, 2016, at 10:46, Chuck Guzis <cclist at
sydex.com> wrote:
One
advantage that DDS (and DLT...) has over most of the "QIC" tapes is that
they use a read-after-write system like the big 1/2" tape drives, making
a separate verification pass unnecessary. They also tend to follow the
ANSI sequantial-access SCSI standard more carefully.
And they also don't have that !@#&%##!^^ belt mechanism in the cartridge!
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
1:13 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 8/21/2016 12:46 PM, Chuck Guzis wrote:
On 08/21/2016 10:12 AM, js at cimmeri.com wrote:
Chuck,
I agree wholeheartedly with your assessment. I do have a
variety of 4mm, 8mm, and DLT tape drives in addition to the
problematic ones discussed earlier. But trying other, novel
mechanisms that contain brilliant design ideas is quite a
bit as fun as well, beyond just the practical concern.
Bet: I think 9 track or DLT will outlast them all, mechanism
longevity included. Specifically, I think my HP 7970E will
likely outlast every other mechanism / media combination I've
got, with the only uncertainty being the longevity of 9 track
media... but there, at least I've got a Mark III tape cleaner.
- John
The final matter is that I'd still like to
get the Teac to function
with some software, just to watch it operate (you have to really
like mechanical things to understand this strange fascination).
Having put some time and $ into the Teac, it'd be nice to get some
reward, even if only then it gets placed on the shelf afterwards.
Back in the day, I wondered if the DDS drives being as complex as they
were, with the skinny less-than-4mm wide tape could even have the
possibility of any longevity.
But the old DDS-1 tapes I recorded more than 20 years ago are still
quite readable as are the DDS-4 tapes I wrote over a decade ago. One
advantage that DDS (and DLT...) has over most of the "QIC" tapes is that
they use a read-after-write system like the big 1/2" tape drives, making
a separate verification pass unnecessary. They also tend to follow the
ANSI sequantial-access SCSI standard more carefully.
You may want to consider DDS or DLT for your DEC gear.
--Chuck
4:08 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/21/2016 01:13 PM, js at cimmeri.com wrote:
I agree wholeheartedly with your assessment. I do
have a variety of
4mm, 8mm, and DLT tape drives in addition to the problematic ones
discussed earlier. But trying other, novel mechanisms that contain
brilliant design ideas is quite a bit as fun as well, beyond just the
practical concern.
Bet: I think 9 track or DLT will outlast them all, mechanism
longevity included. Specifically, I think my HP 7970E will likely
outlast every other mechanism / media combination I've got, with the
only uncertainty being the longevity of 9 track media... but there,
at least I've got a Mark III tape cleaner.
Given good quality media, I suspect that you're right. In theory,
7-track tape should outlast either, but the equipment is getting pretty
hard to find. Same for wide-tape schemes (I mentioned the Honeywell
Datamatic earlier--but there were others).
But strange and weird, if that's your thing, means that you should
probably investigate the really oddball stuff, like wafertape, stringy
floppy--and my personal choice for weird--Datasonix Pereos. 8mm
(Exabyte) drives have a pretty good chance of survival, but their
relatively lower market segment population probably dooms them.
--Chuck
4:47 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/21/2016 04:15 PM, Al Kossow wrote:
nope, the transport has rubber rollers that crack, and
little rubber
belts.
That's the transport; but what are the shortcomings of the medium itself?
FWIW, I've got at least one DDS drive with rubber parts that have turned
to goo.
--Chuck
26 Aug
26 Aug
9:48 a.m.
New subject: Are old SCSI tape drives not all created equal?
On 8/21/2016 6:47 PM, Chuck Guzis wrote:
On 08/21/2016 04:15 PM, Al Kossow wrote:
Which brand & model drives, Chuck?
There appear to be different kinds of
material used for the rollers. For
instance,
with a 1999 OnStream DI30 (parallel port
30gb) ADR drive, it's a typical black
rubber roller like you'd see in many QIC
drives, and it's turned completely to goo.
But the SCSI version of the same drive
-- a 1999 SC30 -- has a red roller that
appears
to be maybe a silicone rubber.. and it's
still in perfect shape.
A 1996 SCSI Seagate DDS-1 DAT drive, on
the other hand, has what I guess is the
pinch roller. It's not gooey, but is
showing cracks.. Seems like a hard,
black rubber.
So at least one type of rubber
liquifies, and at least one type hardens
and cracks.
Very perplexing.
- John
nope, the transport has rubber rollers that
crack, and little rubber
belts.
That's the transport; but what are the shortcomings of the medium itself?
FWIW, I've got at least one DDS drive with rubber parts that have turned
to goo.
--Chuck
10:07 a.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/26/2016 09:48 AM, js at cimmeri.com wrote:
There appear to be different kinds of material used
for the rollers.
For instance, with a 1999 OnStream DI30 (parallel port 30gb) ADR
drive, it's a typical black rubber roller like you'd see in many QIC
drives, and it's turned completely to goo.
So at least one type of rubber liquifies, and at least
one type
hardens and cracks.
Off the top of my head, I recall that the Archive multi-cartridge
(changer) drives were the worst--the turning-to-goo rubber is used in
several places and creates a sticky mess that's almost impossible to
clean completely.
HP drives seem to be pretty durable, however--and I've had good luck
with Sony drives as well.
--Chuck
21 Aug
21 Aug
5:27 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 8/21/2016 6:15 PM, Al Kossow wrote:
On 8/21/16 4:08 PM, Chuck Guzis wrote:
Al,
Is that true for both the full height and half height models?
- John
8mm
(Exabyte) drives have a pretty good chance of survival
nope, the transport has
rubber rollers that crack, and
little rubber belts. 
5:35 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/21/2016 07:27 PM, js at cimmeri.com wrote:
On 8/21/2016 6:15 PM, Al Kossow wrote:
The drives are derived from Sony 8mm video decks, so most of
the transport mechanical parts are all identical to the
video parts. The major difference is in the head wheel. I
think the general kind of parts in both full-height and
half-height drives are pretty similar.
Jon
On 8/21/16 4:08 PM, Chuck Guzis wrote:
Al,
Is that true for both the full height and half height models?
- John
8mm
(Exabyte) drives have a pretty good chance of survival
nope, the transport has
rubber rollers that crack, and
little rubber belts.
5:49 p.m.
New subject: Are old SCSI tape drives not all created equal?
I know it's true for the full height. I've had dozens of dead ones
because of that. I just picked up an 8705 yesterday, will open it up
and also check a 8505
Chuck, I've not had many problems with Exabyte media. DAT on the other hand
has been problematic.
I just got a box of 8mm unix backups that weren't stored well. We'll see how
they do.
On 8/21/16 5:27 PM, js at cimmeri.com wrote:
On 8/21/2016 6:15 PM, Al Kossow wrote:
On 8/21/16 4:08 PM, Chuck Guzis wrote:
Al,
Is that true for both the full height and half height models?
- John 8mm
(Exabyte) drives have a pretty good chance of survival
nope, the transport has
rubber rollers that crack, and
little rubber belts.
6:12 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/21/2016 05:49 PM, Al Kossow wrote:
I know it's true for the full height. I've had
dozens of dead ones
because of that. I just picked up an 8705 yesterday, will open it up
and also check a 8505
Chuck, I've not had many problems with Exabyte media. DAT on the
other hand has been problematic.
I just got a box of 8mm unix backups that weren't stored well. We'll
see how they do.
I've got a few of the beasts, mostly full-height, but my best luck to
date has been using the cheapie 8700--the top-loading unit with the
external power brick (reminds me of the first Sony CD-ROM decks).
I don't know why.
--Chuck
17 Aug
17 Aug
7:09 p.m.
New subject: Are old SCSI tape drives not all created equal?
On 08/17/2016 01:07 PM, js at cimmeri.com wrote:
Hi, folks.
I'm experimenting with various old SCSI tape drives to
see which
will work with my PDP-11/34 with an Emulex SCSI card.
To my surprise, not all SCSI tape drives are created equal.
Right, there was
SCSI, SCSI-II and SCSI-III. Also, a lot of
drives did not correctly support SOME features that others
did. it got VERY messy. Other drives had weird timing
restrictions, or certain commands must be given is a
specific order, or they caused an error or lack of response.
Jon
18 Aug
18 Aug
8:20 a.m.
New subject: Are old SCSI tape drives not all created equal?
Jon Elson wrote:
On 08/17/2016 01:07 PM, js at cimmeri.com wrote:
To wit, from NetBSD's "scsi" man page:
Not every device obeys the SCSI specification as faithfully as it should.
As such devices are discovered by the NetBSD Project, their names are
added to a quirk list compiled into the scsi driver along a list of flags
indicating which particular bad behaviors the device exhibits (and that
the driver should be prepared to work around).
And in the "st" man page:
Because different tape drives behave differently, there is a mechanism
within the source to st to quickly and conveniently recognize and deal
with brands and models of drive that have special requirements.
There is a table (called the ``quirk table'') in which the identification
strings of known errant drives can be stored. Alongside each is a set of
flags that allows the setting of densities and blocksizes for each of the
modes, along with a set of `QUIRK' flags that can be used to enable or
disable sections of code within the driver if a particular drive is rec-
ognized.
And the list of currently defined quirk bits:
#define ST_Q_FORCE_BLKSIZE 0x0001
#define ST_Q_SENSE_HELP 0x0002 /* must do READ for good MODE SENSE */
#define ST_Q_IGNORE_LOADS 0x0004
#define ST_Q_BLKSIZE 0x0008 /* variable-block media_blksize > 0 */
#define ST_Q_UNIMODAL 0x0010 /* unimode drive rejects mode select */
#define ST_Q_NOPREVENT 0x0020 /* does not support PREVENT */
#define ST_Q_ERASE_NOIMM 0x0040 /* drive rejects ERASE/w Immed bit */
#define ST_Q_NOFILEMARKS 0x0080 /* can only write 0 filemarks */
To my surprise, not all SCSI tape drives are
created equal.
Right, there was SCSI, SCSI-II and SCSI-III. Also, a lot of
drives did not correctly support SOME features that others
did. it got VERY messy. Other drives had weird timing
restrictions, or certain commands must be given is a
specific order, or they caused an error or lack of response.
31 Jul
31 Jul
1:23 p.m.
> [keyboard fora] require that I subject myself to
the Web.
> I recognize that few people share this attitude.
Well, I sorta understand; the modern 'active
content' mania causes me
to grind my teeth, too.
Oh, it doesn't make me grind my teeth. I just ignore it. I have no
interest in running software completely untrusted third parties would
like me to run.
But the non-active Web has major benefits.
For you, I daresay it does. It might for me too, if I could stand it.
(There are a very few websites I actually find to be worth subjecting
myself to - tvtropes.org and cracked.com are the only ones that come to
mind offhand.)
It is, of course, not entirely irrelevant that on the few occasions
when I do try to something with the Web, I do it from a classic
machine, usually a SPARCstation-20.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3040
days inactive
3068
days old
44 comments
15 participants
participants (15)
-
aek＠bitsavers.org -
cclist＠sydex.com -
elson＠pico-systems.com -
ggs＠shiresoft.com -
jnc＠mercury.lcs.mit.edu -
js＠cimmeri.com -
jwsmail＠jwsss.com -
macro＠linux-mips.org -
mhs.stein＠gmail.com -
mouse＠Rodents-Montreal.ORG -
nf6x＠nf6x.net -
paulkoning＠comcast.net -
pb＠pbcl.net -
phb.hfx＠gmail.com -
phil＠ultimate.com