SUMMARY -- Problem with 1/2 SCSI Fron-load Tape unit

From: G. Roderick Singleton (gerry@jtsv16.jts.com)
Date: Thu Aug 15 1991 - 15:12:00 CDT


I've received five responses so far and do not except more; hence the
summary. I've ordered them in, what I consider, order of significance.
But do examine all.

Of the five, the first one below, from Michael Sullivan, has helped
solve my problem. Thanks, Michael for a most comprehensive answer.
BTW, I have asked Michael for the numbers of the OEM manuals as I
believe this info will permit me to get a set.

While awaiting responses I entered a call into Sun Canada's customer
service department and received much the same information that Michael
provided except without the detail. According to Sun there are no
SunOS patches that affect the drive; but Mory Katz' message forces me
to scrutenize the available patches much more closely. Hopefully a
patch will be found.

Thanks to all for the quick help,
ger
 
==========================================
Date: Tue, 13 Aug 91 20:44 CDT
From: uunet!trdlnk!mike (Michael Sullivan)
Received: by ariel.tl (4.1/SMI-4.1)
To: gerry@jtsv16.jts.com
Subject: Re: 1/2-inch SCSI problem
Organization: TradeLink Corp.
Cc:

In article <5094@brchh104.bnr.ca> you write:
>I require assistance with one of Sun's 1.2-inch, front-loading tape drives
>(the HP unit) that will _NOT_ complete a multi-volume dump(8) or a sybase
>DUMP DATABASE. These multi-volume backups are performed on a 4/330 with
>a front-loading, 1/2 inch SCSI tape unit. The system is currently running
>SunOS4.0.3 with three 1G-IPI drives.

We have a similar set up here with a 4/380 and what sounds like the same tape
drive (I presume you meant "1/2-inch") except ours came directly from HP. We
are running SunOS4.1.1, but I don't think that is the problem (although I
should warn you that if you are planning on upgrading to 4.1.1, be sure to get
patch 100250-01, which fixes an annoying bug with the MTFSR and MTBSR ioctls
that caused tar appends to silently fail).

>I've tried set size and other parameters to no avail because the dump
>eventually fails with a hard error either at the end of the first volume
>or the end of the second. The errors are generally the same. Likewise,
>using sybase's DUMP DATABASE command prduces similar results. Again
>either at the end of the first volume or the second.



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT