NU013809@NDSUVM1.BITNET (Greg Wettstein) (12/02/89)
I have exhausted all the ideas that I can think of and I am hoping that someon
on the net will be able to shed some light on this problem.
One of my users has an ITT XTRA running XENIX 2.2.1 which supports a
proprietary software package. My user bought the system as a package deal from
a software vendor in California. The system itself has two Megabyte of memory,
a 4-port Digiport card and an 80 Megabyte hard drive so everything is pretty
standard. After doing backups with floppies for about a year my user got tired
of doing this and wanted a tape backup. I was going to use one of my usual
sources but of course the software vendor 'couldn't guarantee that everything
would work right' if we bought from other than them.
The tape drive that showed up was an Archive tape drive and controller board.
Typical of this company the tape system showed up with no documentation other
than a piece of paper on what was written:
Tape Unit configured as follows: BASE 200
IRQ 5
DRQ 3
DACK 3
I installed the controller card in an 8-bit slop and hooked up the tape drive.
I used mkdev tape to install the device driver and configured the driver to use
a port addres of 0200H, an interrupt level of three and the third DMA channel.
I installed the new kernel and re-booted the system to activate it. On bootup
the kernel reported that it had a Type A controller with parameters which
matched the above values.
I popped in a DC-600A tape cartried and used the tape command to retension the
tape. The controller wound the tape forward, rewound it and a tape status
command reported no errors and that the drive was at the beginning of the tape.
I thought to myself, 'We got lucky this time, everything seems to be working.'
I fired up the proprietary backup program that the company supplies, the tape
whirred for a little bit and reported back an errno 6 (??) and quit.
Considering the reputation of this company I immediately suspected their
software.
- They use sparse files in their database, the system reports file sizes
of 30-40 megabytes but in actuality the files only have about 1 to 2
megabytes of data in them. The company claims that this is part of their
software secutity because the normal utilities (tar, cp, cpio) will
dump or transfer the entire file which will end up being most null
space. Their backup utility makes a temporary file composed of only
records which have been marked as written and then dumps this temporary
file to tape or disk.
I switched over to a scratch directory which had half a dozen shell scripts in
it and decided to try out tar to make sure that everything was working right.
I typed: tar -cvf /dev/rct0 *
and the tape drive begin spinning and tar listed out the shell scrips and
their sizes. I thought to myself, 'well thats good, at least the tape drive
is working'. I used the tape command to rewind the tape, created a
sub-directory and tried a final check-out by restoring the files with:
tar -xvf /dev/rct0
The tape drive whirred for a little while and tar reported back with the
message: blocksize=0
I checked the directory and nothing was restored. I tried listing the files
on the archive with tar -tvf /dev/rct0 and the blocksize=0 message was
returned again.
Since then I have tried everything I could think of and read about to get the
tape drive working. I have genned kernels until my eyes are crossed. I
re-jumpered the controller but all that did was make COM1 quit working
(conflicting interrupt problem). I have tried every command option available
to tar and have told tar to use the default devices specification in
/usr/defaults/tar all to no avail.
I am hoping that someone on the net will have some experience or knowledge
that they can share with me. I have a similar drive running on my personal
machine which as an ALR 386/220 running XENIX 2.3.3 and everything works
fine. Any comments or suggestions would be deeply appreciated. I am at
my wits end with both this machine and the company that supplied it.
By the way the company and I are no longer talking because I turned them into
SCO for some shenanigans with trying to sell multiple versions of the same
operating system, i.e., buying one run-time and installing it on every
machine they sell. Any information will be appreciated and a follow-up
posted.
As always,
Dr. G.W. Wettstein
NU013809@NDSUVM1
- The truest mark of a man's wisdom is his ability to listen to other men
expound their wisdom.