We don't see this with our 3494/3590s.

We get back 20 3590s every Wed and they don't expire for 18 days.
(which is usually the following Thurs or Fri of the Wed returns)
We check them in as PRIVATE and within the appropriate 1 or 2 days
they pop-up as scratches.

The returning DB backups are a different matter since they get deleted out
of volhist as soon as they go offsite.  sigh.  Waiting for that new
feature!!!!

... joe.f.

Joseph A Faracchio,  Systems Programmer, UC Berkeley


On Wed, 12 Jul 2000, Cook, Dwight E wrote:

> Something folks might want to try...
> In some environments we've had to take library volumes out of the ATL... now
> if you put them back in (while they contain valid data) you must check them
> in as PRIVATE... well, I think when the data on them expires (or is cleared
> by reclamation) the tape volume remains private rather than rolling back to
> a "scratch" status...(which is how they were checked in to begin with)
> I found a lot of private with no data volumes in the environments where we
> have shuffled a lot of tapes in & out of the ATL...
> Oh, and in checking the volhist the last thing seen is a delete for the
> volume.
>
> and if you are in a unix environment, here is something that will assist in
> doing this...
>
> Take a listing of your LIBVOLS
> Select records that are "Private" & "Data"
>         dsmadmc q libvol | grep Private | grep Data > libvols
> Now take a listing of your volumes with device type of your drives within
> the ATL
>         dsmadmc q vol dev=3590devc > vols
>
> Now how many "data" library volumes are not known to ADSM/TSM ? ? ?
>         for VOL in $(cut -c18-23 libvols)
>         do
>                 grep $VOL vols 1>/dev/null 2>&1
>                 if [ $? -ne 0 ]
>                         then
>                         echo $VOL >> lostvols
>                 fi
>         done
>
> Dwight
>