I am in the process of writing a script to look for these events and simply
cancel them to free up the resources.  But, I am saying the backups are more
important in my environment.  The way my processes are setup in my
environment mitigates a process being canceled.  I had to do it because a
migration can cancel a backup stgpool command or a move data command to get
a drive.

Now, I have never seen this on a migration.  What have you got the maximum
file size set to?  If it is unlimited for the disk pool, that is likely the
problem.  It should be some kind of reasonable number.

I have seen this problem with backup storage pool commands trying to get to
the primary tape that is still being backed up to.  And, for a backup
storage pool command that is trying to get to the tape being migrated to.
Migration always seems to get a new tape so long as there is a tape drive,
otherwise it waits on a mount point in the device class.

If this was the only volume in the storage pool left and no scratches were
allowed or the maximum had been assigned, then I could see how this could
happen.  If you have collocation on, I could also see how this would happen.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Suad Musovich [mailto:s.musovich AT AUCKLAND.AC DOT NZ]
Sent: Thursday, October 10, 2002 2:29 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: migration: waiting for acccess to tape annoyance


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
--