Nice in theory but backup windows tend to stretch over the original
boundaries to suit customer needs and balance the external environment
(backup demand is now bottlenecking the network).

On Fri, 2002-10-11 at 07:51, Miles Purdy wrote:
> A better solution is usually to schedule these events so this never happens. 
> Run migration before any backups start.
>
> Miles
>
>
> >>> s.musovich AT AUCKLAND.AC DOT NZ 10-Oct-02 1:28:48 PM >>>
> Had the below happen to me last night. It actually happens when a node
> backs up a large data file (larger that the stgpool Max) that streams
> directly to tape, then takes it's time.
> The job was a routine migration to empty the diskpool making way for the
> night of the bulk backups
>
> Is there anyway for a migration to timeout for a specific tape?
>
> (I suspect the node, in this case, is on a 10Mb connection and backing
> up a 21GB file)
>
>
> 361     Migration
>                 Disk Storage Pool BACKUPPOOL, Moved Files:
>                 118365, Moved Bytes: 21,245,640,704, Unreadable
>                 Files: 0, Unreadable Bytes: 0. Current Physical
>                 File (bytes): 512,000
>
>                 Waiting for access to output volume UA0283
>                 (19095 seconds).
>
>
> Suad
> --