We have seen the same thing when trying to run in parallel to a collocated
tape pool. When a client goes to back up, it goes through these 5 steps
looking for a tape. If it sees there is one being used that is not full, it
will wait for it. This chunk of text is from the Administrator's Guide.

                How the Server Selects Volumes with Collocation Enabled
When collocation at the client node level is enabled for a storage pool
(COLLOCATION=YES) and a client node backs up, archives, or migrates files to
the
storage pool, the server attempts to select a volume using the following
selection order:
1. A volume that already contains files from the same client node
2. An empty predefined volume
3. An empty scratch volume
4. A volume with the most available free space among volumes that already
contain
data

        It gets stuck on #1.

        One way around it is to run a "move data ####" just to move a couple
of files to a couple of other scratch tapes and then cancel the process.
That it will move a little data to those new tapes "to mark them as that
nodes territory". Next time you run multiple streams, it will see those
other tapes that are "his/hers ;-)" and go to them instead of waiting for
the mounted ones.
        It's a kludge, but in those cases where you don't want to turn off
collocation on that storage pool, it will work. At least it would get you
through your testing.


Ben