Newsgroups: comp.unix.ultrix
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!zardoz.eng.ohio-state.edu!kcgl1.eng.ohio-state.edu!GEOMAGIC
From: GEOMAGIC@kcgl1.eng.ohio-state.edu (Daniel OConnell)
Subject: Re: Problems with Exabyte on a DECsystem 5400
Message-ID: <1991Jun11.224611.4674@zardoz.eng.ohio-state.edu>
Sender: news@zardoz.eng.ohio-state.edu (Usenet news)
Nntp-Posting-Host: kcgl1.eng.ohio-state.edu
Organization: The Ohio State University
References: <638@rc6.urc.tue.nl>
Date: Tue, 11 Jun 1991 22:46:11 GMT

>A few months ago we installed a SI59-Exabyte unit of the manufacturer
>System Industries on our DEcsystem 5400.

>Secondly, are there users of DECsystem 5400's, which successfully use
>Exabyte units of other vendors?
>If this is the case, could you give me some information about these
>vendors and their Exabyte product(s)?

>Thanks in advance for your time and help.

We have a CMD 223 controller in our 5400 working with an Exebyte.
However, working means only that dump and restore, and tar work.
dd operations can fail occasionaly, but dd also fails on our 9-track
and TK-70 since upgrading (downgrading ?) to Sultrix 4.1. This
class of programs has been verified at other Ohio State Univ. sites
and is apparently an operating system device driver bug or something
along those lines.

I have hope (faint) that this is partially resolved in Sultrix 4.2, but
reading the release notes does not encourage much hope. Meanwhile,
a $240,000 seismic reflection processing software package is disabled
until this TMSCP tape problem is fixed. It works with SCSI tape drives
that the software vendor uses. Of course, all our three 5400 tape controllers
make tapes (including SCSI Exebyte) look like DEC TMSCP tapes so we
would have optimal compatibility with DEC TMSCP tape bugs... sigh.

Cheers,
Dan O'Connell
geomagic@geo1s.mps.ohio-state.edu