We've just come upon a need to be able to read, on an IBM-clone-type PC
running MS-DOS, 525 QIC tapes produced on another system (probably a
Unix system).  The PC in question has a 525 QIC drive, Colorado Memory
Systems, along with backup software provided by Colorado.  (I don't
think they actually manufacture the drive itself or anything, but it's
got their label.)  Of course, their software reads & writes stuff in
their own proprietary format.

Does anyone have any idea at all how to do one of the two following things:
- reference the tape drive "directly" - that is, bypassing CMS's
  backup software - to copy a tape file to disk or some such
- produce something that looks enough like Colorado's data format
  that we can use their software to read the tape.  (That is, does anyone
  know anything about Colorado's data format that would allow us to make
  a dumb version of same?)

Any help would be much appreciated.  We've tried their tech support, but
all we get is head-scratching, basically.  I think we can package the data
any way we need to at the other end, if we know what it needs to look like.
Alternatively, if we knew how to access the tape drive, we could presumably
write a C program to pull the data off & write to disk.  But we've never
had to deal something quite like this.

(If it matters: the tape is a SCSI device.)

15 responses total.

This item has been linked to hardware 77.

Gee, I'm not volunteering Grex for this, however, if it's a scsi
device, and it came from a Unix system, and you need to get if
off the tape ....... 2 + 2 ~= 7.3 for sufficiently large
values of 2 and sufficiently small values of 7.3.

Thanks, TS - you're so helpful!

Hmmm, as I thought I said, "I'm not volunteering Grex for this, 
however," ........ mdw/gregc/steve would probably have to
give a definitive answer as to whether the scsi tape unit
could be hooked up to Grex to read the tapes n question.

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".

Dave, in response to your original query, I think your best bet would
be to pull the tape drive and stick it on a unix system. If it is SCSI,
you should be able to access it in a generic fashion from a UNIX box.
Do you know how the tape was written? Tar? cpio? afio? dump?

If you can provide the tape drive itself, I have the necasary hardware
to read the tapes on a UNIX box, and transfer the data to DOS floppies.
Have your company contact me and I'll quote you a price to do this.

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.

Hmmm, The QIC "standards" gennerally only refer to the interface and the
hardware, the physical encoding of the data on the tape. The higher level
"formatting" is ussually vendor specific and Colorado ussually creates
their own formats.

If you want to write tapes that are protable between a UNIX system and DOS
I think you would be better off using Gnu tar. There is a version available
for DOS that talks to the tape drive through the standard ASPI interface.
Question: Is the tape drive in your DOS box hooked up to a SCSI controller
provided by Colorado? Some off-brand odd-ball controller? Or is it hooked
to something more generic like an Adaptec or Buslogic controller?

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.

The solution seems to be to use a media accessable by MS-DOS.  If the data
is small enough, perhaps an MS-DOS formatted diskette?  Since their soon-
to-be system hasn't been purchased, perhaps a diskette drive and a Unix with 
MS-DOdiskette support would solve the problem.  Or, perhaps a different
tape system?

<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!!!

Oh, BTW, a couple of points on this:
- The driver Colorado provides is ASPI2DOS.SYS.  (This is on the system I've
  been momentarily able to test with.)  It looks as if there are also drivers
  called ASPI4DOS.SYS & ASPIEDOS.SYS, FWIW.
- In case anyone else is ever interested: The standards are obtained from
  Quarter-Inch Cartridge Drive Standards, Inc., 311 East Carrillo Street,
  Santa Barbara CA 93101.  Phone (805) 963-3853, fax (805) 962-1541.  They
  seem to operate out of the office of a company called Freeman Associates,
  and that's how the phone is answered.
  (End of Public Service Announcement)

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.

The highest level of formatting I've ever heard of for QIC involves
formatting as fixed sized blocks all of 512 bytes.  I seriously doubt
there's any further notion of formatting after that.  9 track tapes have
variable sized blocks - there may well be a standard for how to do that
somewhere in the QIC set of standards.  You do need to be careful with
QIC, there are many many standards, and almost all of them will be
irrelevant and even wrong for you.  However, if you think the standard
being used is kind of like 9 track tapes, then you should pay attention
to any mention of tape marks, and you should look for a utility called
"ansitape".  There's an ANSI standard for how to store multiple files on
something called an ANSI labelled tape, and this is in fact used by a
variety of vendors, including DEC and IBM.  Ansi labelled tapes aren't
all that hard to decode, so if that's what you got it should be at all
hard to deal with.

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...

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss