response 1 of 15:

Nov 2 06:47 UTC 1994

This item has been linked to hardware 77.

response 3 of 15:

Nov 4 11:40 UTC 1994

Thanks, TS - you're so helpful!

response 5 of 15:

Nov 6 14:26 UTC 1994

I think that should be written as:
    Lim   2 + 2 = 7.3
  2->3.65

Anyway, we *might* be able to hook such a beast to Grex, BUT:
1.) We have way too much to do right now with getting the SCSI devices
    we currently own to all work together in a stable manner. We can't
    add yet another variable/source-of-problems.
2.) Even if things were running fine, we would have to shut the system
    down to hook up your tape drive, and again to remove it. I can't really
    justify inconvieniencing hundreds of users for 1 user. Plus the fact
    that anytime you play with the hardware you risk an "Oops".

response 7 of 15:

Nov 7 01:15 UTC 1994

Reading and writing the tape itself isn't the problem.  It's that
apparently there is some kind of standard now out there for QIC tapes
which includes not only stuff relating to the hardware end of things
but to something like an archive format - *analogous* to tar or cpio or
whatever.  If I write a tape using the Colorado backup software, & then
read it on the Unix QIC, there's a tape file that appears to be a kind
of header for the whole tape.  (I *think* this is what the Colorado
software means when it says the tape is "formatted", & I have a suspicion
that I can just duplicate it.)  Then there's a tape file which includes
some kind of header for each file dumped to tape (all together) and then
(for each file) the *same* file header and the file's data, with what I
think is a 4-byte marker before the entry for each file.  Obviously (because
of what the Colorado software does in restoring files) this includes
date/time/permission-type info, & probably size, but I've been unable to
figure out how all that stuff is encoded - & that's probably all I'll need.

Colorado did give us a phone # for a company in California that serves as
a clearinghouse for the industry standards for QIC tapes, & I've requested
(free!) one doc & the list of available standards.  I'm hoping that this
will answer all my questions, but by no means holding my breath.  (Actually,
what I've learned in following up on all this may answer some other tape-
compatibility mysteries we've seen; that would be a ***BIG*** bonus, if
so.

Unless someone has info at their fingertips for this kind of issue, I'll
see what come out of my next steps (RTFM, as soon as it arrives, & maybe
order more).  I'll report back.  In fact, I'll also try to remember to post
that phone # for the standards sometime when I'm at work (where it's
written down), just in case anyone else ever wants any of this stuff.

response 9 of 15:

Nov 7 13:04 UTC 1994

Hmm.  That's not what they told us.  (And what they told us kind of fits
with some other weird problems we'd had in another situation, as I
mentioned.)

As far as the controller: in the system we were testing it with, I don't
know but could probably find out.  (I'd guess Adaptec, but that's a guess.)
In the case we'd *need* it for, no way to tell.  The problem is that our
clients are going to need to send data from their (hopefully soon-to-be-
purchased) Unix box to some people operating on PC based machines.

If we were to use GNU tar or something like that: that brings us back
where I started, to the issue of how to access the tape from the PC
directly.  *That* I still haven't gotten any leads on.  If you know
anything about how it's done, say on - I'm VERY interested.  And thanks
for your comments so far.

response 11 of 15:

Nov 8 15:28 UTC 1994

<sigh> That would make sense, maybe, and they probably support diskettes
already.  But we're talking about probably a couple of hundred MB of data
a couple of times a year, in this case.

*Does* anyone know how to reference the drivers for such a tape drive?
I mean, something loads in CONFIG.SYS, but I don't think it's something
you can just open as you do (say) LPT1.  Does it hook interrupts or
something?  If I had some technical info on this it would be, if not a piece
of cake, at least pretty doable.

FWIW: I got *part* of what I'd requested of the QIC standards, & at a glance
it looks like (after mucho work deciphering it) it will give me *part* of
what I need to tackle things from that angle.

<BIG sigh>
Thanks for the suggestions, all, & keep them coming if you think of anything
that sounds useful.  Again, what I'm after is something I can write
(likely in C) at either end, or (even better) an easy out-of-the-box
solution.

Um.  One more question, for the more Unix-geek types who read this: in
floundering around I stumbled on the REELexchange stuff.  This apparently
is specifically for R2R tapes, but it almost sounds as though if there were
something analogous for QIC tapes it would be half the battle on *that*
end.  I'm pretty ignorant on this stuff; anyone who knows more is welcome
to jump in.  Thanks!!!

response 13 of 15:

Nov 8 20:54 UTC 1994

davel, have you searched any of the larger ftp sites (like oak.oakland.edu
and garbo.uwasa.fi) for software pertaining to your problem?  They may
not have exactly what you want, but if you're lucky you might find some
source code that will help.

response 15 of 15:

Feb 26 15:16 UTC 1995

The aspiXdos.sys drivers come with Adaptec boards, hence if you use it you sho
ld have one of those. The easiest way that comes to mind would be to install 
LINUX (avail. from sunsite.unc.edu.. make sure you grab FTAPE from there also)
install it and you should have no further problems. I'm using a CMS qic-80 and
an Archive Turbo Python (4 mm DAT) with no problems.    MIKE...