Mary wrote:

> I ran into a situation today where I saw the following:
>
> We have the tape mountlimit set at 3
> We are running 1 and have several other move data processes waiting to
>   run.
> A user requests 4 archive tasks to run (archive will be written to
>   tape)
> One of the archives starts and completes.
> The other 3 archives remain in media wait status for over 2 hrs.
> The move datas continue to run.
> I increase the mountlimit to 7.
> 2 more move data processes take off
> The 3 archives continue to wait.
> I cancel all the move datas.
> The archives finally start.

Here is what I suspect is happening.  Move Datas do have a higher
priority on what we call the mount point wait queue.  This explains
why the move datas are kicking off first, which I know you already
understand.

The question is:  Why, with a mount limit of seven, are only six being
used, (by three move data processes).  The seventh drive is available
but not being used. Here is my guess:

I think there are probably four move data processes involved.  Three of
the move data processes are actively using drives.  The fourth move data
process is at the head of the wait queue.  The archive sessions are
in line behind this fourth move data process.  The move data process
waiting needs TWO drives, but there is only one available, so it

continues to wait.  The code doesn't allow right now for an archive
session on the wait queue to jump ahead of the move data process
waiting.   However, if a new archive session came in, I believe it would
claim that drive.  So anyway, that it how I believe the code is
behaving.

Dave Crockett
ADSM development