Well, I don't know if this will help or not.  The short answer is that
you need to upgrade your server code.

At 3.1.2.20 on AIX, I had a frequent problem with queries hanging.  As I
recall there was not a lot of consistency in which queries would hang,
and no good way to prevent it.  May or may not apply to your situation.
Some of the hangs are documented in the README for the 3.7.x server, in
the "apars fixed" section.

Hangs are most likely to occur when there is a lot of data base activity
-other queries, DELETE FILESPACE commands, EXPIRE INVENTORY commands,
large SELECTS.  If you can schedule your script to run so that it
large SELECTS.  If you can schedule your script to run so that it
doesn't compete with any of those, it may help.  But it may not - there
were also cases where something simple like a Q PROCESS could hang it,
too.  And at 3.1.2.xx, we couldn't do a SELECT on the CONTENTS table
EVER without a hang!

If you can check the server activity log carefully, you can usually see
which query was the last to be issued.  It may or may not help you to
know exactly which query is hanging, depending on which query, you might
be able to write it differently.

Try this:

If you think the script is hung, enter this command:  Q  SESSION F=D

Look at the session numbers.  Hung queries will just sit there for ages,
while other backup/restore sessions will come and go.  If you see a
session with a very low number, that is probably the hung one.  If you
cancel it, it may free yours up.  If the ancient query is yours, it's
hung and isn't going to free up.  We even had cases where the only way
to free things up was to bounce the server.


There is a SHOW LOCK command that Tivoli support could track through and
tell you exactly what is hung waiting on what.  However, 3.1.2.20 is
about to go out of support (Jan. 31, I believe), and THE ONLY FIX is to
upgrade the server code, anyway, so you would probably be better off
pursuing that.  I'm at 3.7.2 now, and we see this type of problem much
less frequently.