> So the STUs are oversubscribed by "1".
> 
> It seems jobs won't "queue", but re-try, over and over and over, every
> approx 15 seconds, each time throwing a status 134, then "requeuing" for
> a couple seconds, then retrying.

That's exactly the behavior I've seen.  It appears that after being
queued, it looks for an STU.  The STU has room so it is activated.
After activating, then STU discovers that no drives are available and
the job is given a 134.

> Is it possible to get the re-trying job to just "queue" properly and
> wait untill there is a drive available?

I don't know how to get it to do so.  Hopefully someone else can make
some suggestions.

> The behavious right now, seems kind of dirty.
> 
> Is this what happens when you have drives shared with SSO?
> Ie. Jobs assigned to a given media server behave like this from the time
> the window opens, untill a drive is available for that media server?

In my case, it didn't even involve SSO.  It was a single robot that had
multiple STUs defined.  The STUs had drive counts to prevent any one
STU from grabbing more than a few drives.  But in total, they were
overcommitted. 

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >