Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!mips!cs.uoregon.edu!ogicse!unmvax!nmt.edu!nraoaoc
From: rmilner@zia.aoc.nrao.edu (Ruth Milner)
Newsgroups: comp.unix.aix
Subject: Re: RS/6000 Tape questions
Message-ID: <1991Apr30.201002.24679@nmt.edu>
Date: 30 Apr 91 20:10:02 GMT
References: <1991Apr24.230308.17971@nmt.edu> <496@nwnexus.WA.COM> <595@ariel.ucs.unimelb.edu.au>
Reply-To: rmilner@zia.aoc.nrao.edu (Ruth Milner)
Organization: National Radio Astronomy Observatory, Socorro NM
Lines: 38
Cc: rab@tauon.ph.unimelb.edu.au

In article <595@ariel.ucs.unimelb.edu.au> duty@ariel.ucs.unimelb.edu.au (Duty Programmer) writes:
>In article <496@nwnexus.WA.COM> wjones@nwnexus.WA.COM (Warren Jones) writes:
>>rmilner@zia.aoc.nrao.edu (Ruth Milner) writes:
>>
>>>unusual ... compared to the Suns. For example, on a Sun, if you write a file
>>>onto Exabyte, you can take it away and later on put it back in, skip to the
>>>end of that file, and write another one. On the RS/6000, not only will it not
>>>do this at all (I/O error), but if you take a tape with a file written on it 
>>>by the IBM over to the Sun, the Sun won't write at the end of it any more 
>>>either! 
>
>I sympathise. The AIX tape i/o has been driving me crazy for several weeks.
>
>However, I think this last problem you mention may be something else. You don't
>mention whether you can read the IBM tapes on the Sun. If you can't, then it
>may be that the Sun is using CRC error correction and the IBM is using ECC.

Yes, the data that has been written can be read back (we'd have found out
*very* quickly if this weren't the case). But you cannot do an "mt fsf 2",
for example, and then start writing at the end of the second file the IBM
wrote. When the first n files were originally written by the Sun, the Sun
has no trouble skipping over and starting to write.

Also, this doesn't explain why the IBM can't append to its own tapes. If it
is truly a restriction in the hardware, then it is a restriction that IBM
has added, not one that Exabyte put in. This *severely* restricts the
usefulness of the drive. 

"smit" gives no information about choosing an error detection/correction
method. However, it does ask whether to use "extended file marks". The
default appears to be "no"; should I change this to "yes"? Is the problem
simply that the file marks aren't long enough (?) for positioning purposes? 
I vaguely recall reading somewhere the distinction between short and
extended file marks, but I don't remember the details now on the effects.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
Computing Division Head      rmilner@zia.aoc.nrao.edu