Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

On 08/26/2016 09:48 AM, j...@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

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

On 8/21/2016 6:47 PM, Chuck Guzis wrote:

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



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

Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

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

Re: Are old SCSI tape drives not all created equal?

[Al Kossow]

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, j...@cimmeri.com wrote:
> On 8/21/2016 6:15 PM, Al Kossow wrote:
>>
>> On 8/21/16 4:08 PM, Chuck Guzis wrote:
>>>   8mm
>>> (Exabyte) drives have a pretty good chance of survival
>> nope, the transport has rubber rollers that crack, and
>> little rubber belts.
> 
> 
> Al,
> 
> Is that true for both the full height and half height models?
> 
> - John

Re: Are old SCSI tape drives not all created equal?

[Jon Elson]

On 08/21/2016 07:27 PM, j...@cimmeri.com wrote:

On 8/21/2016 6:15 PM, Al Kossow wrote:


On 8/21/16 4:08 PM, Chuck Guzis wrote:

  8mm
(Exabyte) drives have a pretty good chance of survival

nope, the transport has rubber rollers that crack, and
little rubber belts.



Al,

Is that true for both the full height and half height models?

- John

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

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

On 8/21/2016 6:15 PM, Al Kossow wrote:


On 8/21/16 4:08 PM, Chuck Guzis wrote:

  8mm
(Exabyte) drives have a pretty good chance of survival

nope, the transport has rubber rollers that crack, and
little rubber belts.



Al,

Is that true for both the full height and half height models?

- John

Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

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

Re: Are old SCSI tape drives not all created equal?

[Mike Stein]

- Original Message - 
From: <j...@cimmeri.com>
To: <gene...@classiccmp.org>; "discuss...@classiccmp.org:On-Topic and Off-Topic 
Posts" <cctalk@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:<j...@cimmeri.com>
>> To:<gene...@classiccmp.org>; "discuss...@classiccmp.org:On-Topic and 
>> Off-Topic Posts"<cctalk@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, j...@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%20Commands.pdf
>>>>
>>>> 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
>>>
>>>
>>>
>>>
>>>
>>

Re: Are old SCSI tape drives not all created equal?

[Al Kossow]

On 8/21/16 4:08 PM, Chuck Guzis wrote:
>  8mm
> (Exabyte) drives have a pretty good chance of survival

nope, the transport has rubber rollers that crack, and
little rubber belts.

Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

On 08/21/2016 01:13 PM, j...@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

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

On 8/21/2016 12:46 PM, Chuck Guzis wrote:

On 08/21/2016 10:12 AM, j...@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



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

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

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:<j...@cimmeri.com>
To:<gene...@classiccmp.org>; "discuss...@classiccmp.org:On-Topic and Off-Topic 
Posts"<cctalk@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, j...@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%20Commands.pdf

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

Re: Are old SCSI tape drives not all created equal?

[Mark J. Blair]

> On Aug 21, 2016, at 10:46, Chuck Guzis  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 
http://www.nf6x.net/

Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

On 08/21/2016 10:12 AM, j...@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

Re: Are old SCSI tape drives not all created equal?

[Mike Stein]

What are you using to send/receive the commands?

m


- Original Message - 
From: <j...@cimmeri.com>
To: <gene...@classiccmp.org>; "discuss...@classiccmp.org:On-Topic and Off-Topic 
Posts" <cctalk@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, j...@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%20Commands.pdf
>>
>> 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
> 
> 
> 
> 
>

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

On 8/19/2016 1:08 PM, Chuck Guzis wrote:

On 08/19/2016 09:24 AM, j...@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%20Commands.pdf

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

Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

On 08/19/2016 01:28 PM, j...@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

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

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, j...@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.

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

On 8/19/2016 2:16 PM, Chuck Guzis wrote:

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



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

Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

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

Re: Are old SCSI tape drives not all created equal?

[Al Kossow]

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, j...@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.
>>

Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

On 08/19/2016 09:24 AM, j...@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%20Commands.pdf

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

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

On 8/17/2016 6:17 PM, Chuck Guzis wrote:

On 08/17/2016 02:59 PM, j...@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).


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



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

Re: Are old SCSI tape drives not all created equal?

[Jon Elson]

On 08/17/2016 01:07 PM, j...@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

Re: Are old SCSI tape drives not all created equal?

[Chuck Guzis]

On 08/17/2016 02:59 PM, j...@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

Re: Are old SCSI tape drives not all created equal?

[Phil Blundell]

On Wed, 2016-08-17 at 16:59 -0500, j...@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.

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

On 8/17/2016 2:38 PM, Chuck Guzis wrote:

On 08/17/2016 11:07 AM, j...@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.


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









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

Re: Are old SCSI tape drives not all created equal?

[Paul Berger]

On 2016-08-17 4:11 PM, Guy Sotomayor Jr wrote:

On Aug 17, 2016, at 12:01 PM, Maciej W. Rozycki  wrote:

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.


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

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.

Re: Are old SCSI tape drives not all created equal?

[Guy Sotomayor Jr]

> On Aug 17, 2016, at 12:18 PM, Paul Koning  wrote:
> 
> 
>> On Aug 17, 2016, at 3:11 PM, Guy Sotomayor Jr  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.

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

Re: Are old SCSI tape drives not all created equal?

[j...@cimmeri.com]

Thanks very much, Mouse, Paul, Maciej, 
and Guy for helping me
understand my SCSI tape drives.  I had 
no idea!


- John

Re: Are old SCSI tape drives not all created equal?

[Paul Koning]

> On Aug 17, 2016, at 3:11 PM, Guy Sotomayor Jr  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

Re: Are old SCSI tape drives not all created equal?

[Guy Sotomayor Jr]

> On Aug 17, 2016, at 12:01 PM, Maciej W. Rozycki  wrote:
> 
> 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.
> 

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

Re: Are old SCSI tape drives not all created equal?

[Paul Koning]

> On Aug 17, 2016, at 3:01 PM, Maciej W. Rozycki  wrote:
> 
> 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.

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

Re: Are old SCSI tape drives not all created equal?

[Maciej W. Rozycki]

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

Re: Are old SCSI tape drives not all created equal?

[Paul Koning]

> On Aug 17, 2016, at 2:07 PM, j...@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

Re: Are old SCSI tape drives not all created equal?

[Mouse]

> 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 HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B