[daip] tape probs (fwd)

[Patrick P. Murphy]

On Thu, 18 May 2000 08:59:33 -0600 (MDT), Meri Stanley
   <mstanley at aoc.nrao.edu> said: 

> ----- Begin Included Message -----

> From: Debra Shepherd <dshepher at aoc.nrao.edu>
> To: Meri Stanley <mstanley at zia.aoc.NRAO.EDU>
> cc: Debra Shepherd <dshepher at zia.aoc.NRAO.EDU>
> Subject: tape probs (fwd)

> Ka Chun Yu (the visitor on tesuque a couple of weeks ago) is having tape
> read problems with his calibrated OH line data.  Do you have any
> suggestions about how to solve this problem?  His e-mail to me about the
> problems he has been having is appended below.  

> ---------- Forwarded message ----------
> Date: Wed, 17 May 2000 20:05:08 -0600 (MDT)
> From: Ka Chun Yu <kachun at casa.colorado.edu>
> To: Debra Shepherd <dshepher at zia.aoc.NRAO.EDU>
> Subject: tape probs

> I manage to load ch0sav and linsav (the saved tables for channel 0
> and the line data), then the ch0nrf (no RF channel 0) data, all quite
> successfully.  Then FITLD automatically went onto the final file, the
> line data set which is enormous--about 1 GB.  I go away and come back
> to find:

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

and see how much of the last file can be read to disk.  This assumes the
tape is not blocked; if BLOCKED=TRUE was set on writing, the "bs" or block
size should be 28800.  You will also need enough disk space to accomodate
the file before trying this experiment.  

You need to use the right tape drive name (no-rewind device!) for your OS
(note that 0ln is zero, the lowercase letter "L", and the lowercase letter
"N").  I show Solaris above; for Linux use /dev/nst0.

If you get an error message, or the status return ($status on some csh
shells) is non-zero, then my hunch about there being a problem with the
tape or the drive is likely right.

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

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

> The three possibilites for what is wrong are: (1) the way aips is set up
> here is screwy (software problem); (2) the tape drive is just not
> cooperating with aips (hardware problem); (3) or the tapes weren't
> written properly at the AOC.  Any ideas from your end?

I'd suggest options 2 or 3.  The tests I propose above may help determine
which if any are right.

				- Pat
-- 
  Patrick P. Murphy, Ph.D.            Division Head, Charlottesville Computing
  (804) 296-0372, 296-0236                National Radio Astronomy Observatory
  Home: http://www.goof.com/~pmurphy/   Work: http://www.cv.nrao.edu/~pmurphy/
   "Linux is Inevitable."  "Why?"  "Because it's alive!" - John MadDog Hall