I'm not one to let a good thread die, so .... :).

  I agree with Bob, there is no affinity between physical tape media and a
physical tape drive.

  However, what would have happened (and caused VX support to suggest
bpexpdate'ing the media) is a RVSN/EVSN mismatch.  Consider a pair of brand
new SL8500s, with new media and a mismatched drive configuration.  Kicking
off a large number of backup will cause a large number of media to show up
in drives.

  Any given backup job mounting a new tape only cares that a tape shows up
in the /dev/rmt which it expects.  If tape id T1 is requested to D1, but T2
shows up in D1, your backup job has no way to know there is a problem.  The
mt status says "media present", and the job goes on it's way.  The tape,
however, is physically labeled T1, yet is a RVSN of T2 (i.e. RVSN != EVSN).

  During the next backup cycle, a request for T1 will show a RVSN of T2,
and the mount errors should begin.

  What I don't know is if expiring the media, will cause NetBackup to write
a new VSN during the next backup cycle.

  Justin, you might consider re-bplabeling your media to prevent future
problems.

  Cheers
  Mike


>If the drives are incorrectly addressed, then backups are run, and then the
>drives are
>correctly addressed, those tapes previous written to will upon a next mount
>request will be
>mounted into the incorrect drive and result in an error.
 
>I too have done this (more times than I care to think about) and when
>working with Veritas
>support received the same resolution (going back to 3.1) about using
>bpexpdate.
 
>I don't recall if there was any documentation about this at the time but
>I'm thinking that information
>may be stored in the non-dot-f file or in one of the DB's on the media
>server (/volmgr/database).