Be careful about what you're wishing for there.  What you're saying, in
effect, is you'd rather a single backup run to completion than have your
daily DR preparation processing complete.  In other words, you're putting
the ability to locally restore files from this node above the ability to
recover your environment in the case of a disaster.

My preference, and likely that of most everyone else reading this, would be
to cancel the backup session, and let that one node be exposed.  Then spend
some time trying to track down why the backup was running so long.

This is one of the reasons to still have a DASD pool in front of your VTL.
VTL's are treated by TSM as tape, so some of the "bad" things about working
with tape still apply.

Nick Cassimatis

----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 11/20/2008 07:59 AM
-----

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 11/19/2008
05:32:39 PM:
> Re: "Waiting for access to input volume"
> Shawn Drew
> to:
> ADSM-L
> 11/19/2008 05:33 PM
> Sent by:
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> Please respond to "ADSM: Dist Stor Manager".
>
> It's intermittent slow backups that can sometimes occupy the virtual tape
> like this.
> I would like to make sure that a single slow backup doesn't hold up the
> whole "Life Cycle".   I would prefer to have the single Backup Storage
> pool process fail and move to the next step in the housekeeping script
> than having to cancel the backup manually when I happen to notice this
> happening.  If I can't find a time-out, then I will setup a monitor
script
> to cancel if the wait time gets too large)
>
> Any ideas?
>
> Regards,
> Shawn
> ________________________________________________
> Shawn Drew