Bill,

That used to bother me, too.  I opened a PMR about six years ago about it.
 Then I took a close look at how our system was operating.

In our case, we run maintenance processes, including copypool reclamation,
weekly.  Those processes often run for a day or two.

If we have copypool  reclamation, and storage pool backups running
simultaneously, each process will attempt to manage its own set of tapes.
Each process will start with a "filling" tape, but grab a scratch when
that tape fills up.

Our "offsite" tape library has four drives.  If copypool reclamation is
running when the daily storage pool backups launch, we will have three
storage pool backup processes and the one reclamation process running with
each using a tape.   Now, suppose that two of the three storage pool
backup processes complete, leaving their tapes in "filling" status, but
the reclamation is still running.

And then the reclamation target tape fills up.  If it grabbed one of the
"filling" tapes rather than a scratch, and it was still running when it
came time to pull tapes for the daily vault run, then I would have to
either:
1) stop the reclamation; force a dismount, pull all copypool tapes, and
restart reclamation, forcing the import of a new scratch; or
2) let reclamation run, and leave "new" data copies in the library while
we "believe" that all new data has gone to the vault.

By having that reclamation process grab a scratch, even though there are
"filling" tapes, it means that I can leave reclamation running, and leave
its output tape in the library, and all the new data copies still make it
to the vault.  Should some disaster occur after the tape pull for the
vault, then any data "lost" on that output tape would still be present in
the vault at the time of the latest DB backup point by virtue of the reuse
delay.

Much easier to recover from the disaster, and much less risk of losing
data.

So I've stopped complaining about that behavior.  It's  a feature.

Tab Trepagnier
TSM Administrator
Laitram, L.L.C.





"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 02/07/2006
09:55:18 PM:

> I've noticed that processes will fill a tape and then instead of
> calling for another FILLING tape in the storage pool, it will mount
> a scratch tape. I just saw this again this morning...I had a BA STG
> running from onsite tape to offsite tape. There were 4 tapes in
> the offsite pool...2 filling.. 1 full..and a filling tape being
> written to. The current tape filled up and instead of mounting one
> of the other 2 filling tapes, a new scratch tape was called for. And
> one of the filling tapes was only 1.4% used!
>
> I search the TSM site and the archives, but I must not have the
> correct search words, 'cause I can't find any hits. My TSM server is
> 5.3.2.1 on AIX 5.3 ML2.
>
> Bill Boyer
> "Growing old is mandatory, growing up is optional" - ??