In our case, these occur when there is a problem mounting a database backup
tape.  The TSM server request the mount and marks the volume private.  When
the mount fails, TSM neither enters it as a dbbackup in the volhistory nor
does it return it to the scratch pool.  I learned this when a faulty drive
caused all scratch tapes to become private.  When this happens, I just check
the tape out and then check it back in as scratch.  TSM will not check it in
unless its empty.

On Wed, 27 Mar 2002, Michael Benjamin wrote:

> This seems like normal behaviour...
>
> q vol
> q drm
> q libvol
> q content
>
> Will return nothing for a library volume marked Private with no last
> use. It has not been allocated to a storage pool, the library doesn't
> know anything about it, except the fact it's been marked as private
> and therefore not to use it unless requested. The request never occurs of
> course and your library can
> fill up with nolastuse tapes.
>
> Check out any tapes in this state, run the above commands and see if
> there is any data on them, if not then you can relabel the tapes as
> scratch or just check them back in as scratch and problem solved.
>
> More than likely a scratch tape loaded with a write protect.
>
> > -----Original Message-----
> > From: Gene Greenberg [SMTP:Gene_Greenberg AT ROUNDROCKISD DOT ORG]
> > Sent: Tuesday, March 26, 2002 9:30 PM
> > To:   ADSM-L AT VM.MARIST DOT EDU
> > Subject:      Tapes Blank Under Last Use
> >
> > Hi,
> >
> > I don't get stumped too often, no more than once a day, but I've run
> > into a couple of problems I can't figure out.  I'm using a 3575
> > library with server
> > running 4.3.3 aix. For the last two or three days I'm getting nothing
when
> > I run
> > an eject script.  When I run a q libv I have tapes that have nothing in
> > the
> > column under last use.  When I try to query the volume under the q vol
> > command
> > or q drmedia command nothing comes up.
> >
> > Going through the act log I'm getting many messages of volumes that
> > are marked offsite and still contains files which could not be move
> > ANR1163W.  I don't know
> > how we got to this point, but if anyone has any ideas please let me
know.
> >
> > Thanks,
> >
> > Gene
>
> **********************************************************************
> ****
> Bunnings Legal Disclaimer:
>
> 1)      This document is confidential and may contain legally privileged
>         information. If you are not the intended recipient you must not
>         read, copy, distribute or act in reliance on it.
>         If you have received this document in error, please telephone
>         us immediately on (08) 9365-1555.
>
> 2)      All e-mails sent to and sent from Bunnings Building Supplies are
>         scanned for content. Any material deemed to contain inappropriate
>         subject matter will be reported to the e-mail administrator of
>         all parties concerned.
>
> **********************************************************************
> ****
>