Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!zaphod.mps.ohio-state.edu!swrinde!ucsd!hub.ucsb.edu!appmag!curly.appmag.com!pa
From: pa@curly.appmag.com (Pierre Asselin)
Newsgroups: comp.unix.aix
Subject: Re: RS/6000 Tape questions
Message-ID: <709@curly.appmag.com>
Date: 1 May 91 15:45:44 GMT
References: <1991Apr24.230308.17971@nmt.edu> <496@nwnexus.WA.COM> <595@ariel.ucs.unimelb.edu.au> <1991Apr30.201002.24679@nmt.edu>
Reply-To: pa@curly.UUCP (Pierre Asselin)
Organization: Applied Magnetics, Goleta, CA
Lines: 24

In article <1991Apr30.201002.24679@nmt.edu>
rmilner@zia.aoc.nrao.edu (Ruth Milner) writes:
> 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.

I pulled the following from IBMLink (APAR IX18487).  I didn't try it
myself.  Hope it helps.  Does it do any good with the Sun?

  Problem conclusion: this is a limitation of the tape drive.  "write" is
  only allowed either at the beginning of a tape (bot) or at the end of a
  tape (eot).  The user can still write to the tape after rewind and
  forward it to the last file written by issuing an extra "read" to the
  tape.  This extra "read" will put the tape at eot position.
  Here is a scenario:
      - echo "test 1"   dd of=/dev/rmt0.5 bs=512b conv=sync
      - echo "test 2"   dd of=/dev/rmt0.5 bs=512b conv=sync
      - tctl -f /dev/rmt0.5 rew
      - tctl -f /dev/rmt0.5 fsf 2
      - dd if=/dev/rmt0.5 bs=512b     # ====extra read=====
      - echo "test 3"   dd of=/dev/rmt0.5 bs=512b conv=sync

--Pierre Asselin, R&D, Applied Magnetics.  I speak for me.