[daip] tape probs

[Ka Chun Yu]

Hi Patrick,

> >   FITLD1: Create 20000430    .LINE  .   1 (UV)  on disk  4  cno    6
> >   FITLD1: TAPIO: RECORD LENGTH  24318 INCONSISTENT WITH BLOCK SIZE  2880
> 
> This looks to me like a bad record on the tape, or a bad read.  In either
> case it's likely a drive/media problem.  One way of verifying this would
> be to use Unix utilities to read the tape, e.g. if it's the fourth file on
> the whole tape, do this:
> 
>     bash$ mt -f /dev/rmt/0ln rewind         (make sure you're at the start)
>     bash$ mt -f /dev/rmt/0ln fsf 3          (skip the first three files)
>     bash$ dd if=/dev/rmt/0ln of=FILE4.FITS bs=2880
>     bash$ echo $?
>     0
>     bash$     

I followed your advice with the following commands and results:

  > mt -f /dev/rmt/0ln rewind
  > mt -f /dev/rmt/0ln fsf 3           
  > dd if=/dev/rmt/0ln of=FILE4.FITS bs=28800
  read: I/O error
  18112+1 records in
  18112+1 records out
  > echo $?
  2

It did manage to write out (I'm guessing) about half the line data:

  -rw-r--r--   1 kachun   521650174 May 18 15:00 FILE4.FITS

> >   FITLD1: This usually means you're at END-OF-TAPE
> 
> ... but not always.  Though it may have been a short read followed by an
> EOF (end of file) that was actually on the tape.  Another experiment you
> could try if you have Solaris is:
> 
>     bash$ tcopy /dev/rmt/0ln
> 
> which will tell you how many files are on tape, and how many records.
> It'll also show total size, so you will know if the capacity of the tape
> was likely exceeded (2.2G for Exabyte 8200, 5G for 8500, etc.)

Similarly I run:

  > tcopy /dev/rmt/0ln
  file 1: records 1 to 132: size 28800
  file 1: record 133: size 2880
  file 1: eof after 133 records: 3804480 bytes
  eot
  total length: 3804480 bytes

I tried tcopy on another tape drive attached to a different machine
with the same results.  Does this mean the data is unrecoverable?  If
so, I will try to download what I can off the two tapes that I have
and see about getting replacement raw data from AOC.

> >   FITLD1: Destroyed  1 extension files of type HI
> >   FITLD1: Destroyed UV image file: catno=      6 disk= 4
> >   FITLD1: Purports to die of UNNATURAL causes
> 
> > After all this effort and after this error, aips has helpfully deleted
> > the three previous files on disk (ch0sav, linsav, ch0nrf)
> 
> If you were merging them into the same UV dataset, I can understand why
> AIPS might do this, but if you were reading them into separate UV files,
> then there's something seriously wrong.

Yes they are suppose to be to separate files...

--kachun  +**  Center for Astrophysics and Space Astronomy, CB 389  **+
          +**    University of Colorado, Boulder, CO 80309          **+
          +**  Email: kachun at casa.colorado.edu                      **+
          +**  http://casa.colorado.edu/~kachun                     **+