On Wed, 8 Oct 1997, Mark Adams wrote:

> ADSM will always move big files first if they won't fit in the diskspool
>
> Mark A. Adams
> UNIX SYSTEMS ADMINISTRATOR
> (402) 963-7369 Office
> (402) 444-0754 Pager
> Communications Marketing Services
> SITEL Corporation
> 7444 Farnam
> Omaha, NE 68114
>

Well, this wasn't exactly my point here. Files that don't fit in the
diskpool will be moved directly to another tape-volume. That's no problem.
By the way, I'm quite shure that when moving data off a tape volume with
the move data command, the tape is read sequentially.

My point is that after one of these big files have meen moved to another
tape-volume, this volume and the tapedrive is locked for the rest of the
move-operation, even if all the rest of the files are moved to the
disk-pool.
The only workaround I have found is to cancel and restart the move-
operation.
It seems to me as if a lock isn't freed like it should..


> >-----Original Message-----
> >From:  Tom Tann{s [SMTP:tom.tannas AT USIT.UIO DOT NO]
> >Sent:  Wednesday, October 08, 1997 8:38 AM
> >To:    ADSM-L AT VM.MARIST DOT EDU
> >Subject:       Move data question
> >
> >I have noticed a strange thing during some move data operation from tape
> >to a diskpool.
> >
> >If, during this operation, a file is "redirected" to another tape due to
> >the maxsize-parameter of the diskpool, an output-tape will be mounted to
> >store this file.
> >
> >The strange thing is that this outputvolume is shown as "Current output
> >volume" in the show proc output, and has status of "in use" in show
> >mount output for the rest of the move process operation.
> >Only the one big file was transferred to the tape. The rest was
> >transferred to the diskpool. And the big file was not the last file on the
> >input-volume (actually, it was one of the first).
> >
> >Bug or feature?
>