Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: datri@convex.com (Anthony A. Datri)
Newsgroups: comp.sys.sun
Subject: Re: DAT Drives under SunOS 4.1.1
Keywords: No Digest Subjects in Unmoderated Mode
Message-ID: <3107@brchh104.bnr.ca>
Date: 4 Jun 91 18:40:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sunspots, Psuedo-Unmoderated
Lines: 53
Approved: sun-spots@rice.edu
X-Original-Date:    Fri, 10 May 1991 21:32:03 GMT

>drive in 1/4 inch streaming tape compatibility mode.  The Python is 100%
>compatible with the ARCHIVE VIPER streamer tape,

If that were true, then it would return a product code like "ARCHIVE VIPER".
Mine returns "ARCHIVE Python 25501-xxx".

>for about 6 months, but ran into trouble when we upgraded our SPARC 1 to a
>SPARC 2 which requires SUNOS 4.1.1

I'm using the above Python on an SS2 right now:

  /* Archive python DAT */
  {
        "Archive Python", 14, "ARCHIVE Python", ST_TYPE_ARCHIVE_DAT, 512,
        (ST_AUTODEN_OVERRIDE | ST_BSF),
        400, 400,
        { 0x00, 0x00, 0x00, 0x00},
        {  0, 0, 0, 0 }
  },

The only problem I've seen is if I do something like this:

  tar cf /dev/rst1 foo
  tar cf /dev/rst1 foo
  tar cf /dev/rst1 foo
  tar cf /dev/rst1 foo

Every other command gets an I/O error, with the following to the console:

st1:    Error for command 'write', Error Level: 'Fatal'
        Block: 120504   File Number: 0
        Sense Key: Media Error
        Vendor (Archive Python) Unique Error Code: 0x3b

Putting "mt -f /dev/rst1 rew" after the tar makes the problem go away.  This
isn't really much of a problem, though, since it's a pretty silly thing to
do to begin with.

Oh yeah -- an mt reten gets

   /dev/rst1 retension 1 failed: Inappropriate ioctl for device

but that doesn't bother me all that much either.

I'm getting ~150k/sec writing to the drive with dump, which isn't bad, since
the manual claims a peak rate of 183k/sec.

--


  Fly to the sky on GI-GI____________ and shout to
datri@convex.com