Darlene,

you were the victim of a bug;  I am attaching the apar below.
This bug bit me once too.  I didn't recognize it from your previous
post, but this post rang a bell with me.  It is fixed at the 3.7.2 level.
I don't know what level of 3.1.2.* has the fix.

Bill
- -
Item PQ33718

  APAR Identifier ...... PQ33718       Last Changed..00/01/27
  SERVER HANG DURING BACKUP STORAGEPOOL IF WAIT=YES OPTION IS USED


  Symptom ...... IN INCORROUT         Status ........... CLOSED  PER
  Severity ................... 2      Date Closed ......... 99/12/09
  Component .......... 5697TSMVS      Duplicate of ........
  Reported Release ......... 370      Fixed Release ............ 999
  Component Name TIVOLI STR MGR       Special Notice
  Current Target Date ..00/03/27      Flags
  SCP ...................
  Platform ............

  Status Detail: ASSIGNMENT - APAR has been assigned to a
                              programmer.

  PE PTF List:

  PTF List:
  Release 370   : PTF not available yet


  Parent APAR:    IY03390
  Child APAR list:


  ERROR DESCRIPTION:
  SERVER HANG DURING BACKUP STORAGEPOOL IF WAIT=YES OPTION IS USED
  If a backup stg process is started in foreground the according
  SmAdminCommandThread uses the function bfWaitRemainingCopyProcs
  for synchronization with the backup threads. If this function
  is called with an invalid handle it can loop (or even abend)
  thru the global list of copy-control-blocks.Since it is holding
  a mutex on BFV when processing this list it can block other
  threads.


  LOCAL FIX:
  Use wait=no option on backup stg commands.


  PROBLEM SUMMARY:
  ****************************************************************
  * USERS AFFECTED:                                              *
  ADSM V310 and ADSM V312 server users.  Also Tivoli Storage
  Manager V370 server users.
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  The processing for BACKUP STORAGEPOOL with the WAIT=YES
  parameter may hang and/or abend the server.
  ****************************************************************
  * RECOMMENDATION:                                              *
  Apply the ptf that resolves this fix once it is available.
  ****************************************************************
  The BACKUP STORAGEPOOL processing with the WAIT=YES parameter
  has been altered.  Specifically, the algorithm used to manage
  waiting for completion when the WAIT=YES parameter is
  specified has been altered to prevent a possible hang
  condition or server abend.  The nature of the problem
  depends on timing between multiple threads on the server
  and memory that is shared between those threads.


  PROBLEM CONCLUSION:
  The BACKUP STORAGEPOOL processing with the WAIT=YES parameter
  was not sharing memory properly between threads.  Because
  of this memory sharing error the process could cause the
  server to hang or else abend depending upon the state
  and usage of the memory.
- -
In <NY3d832f-50145973 AT sficorp DOT com>, on 09/18/00
   at 04:57 PM, Darlene E Wnukowski <Darlene.Wnukowski AT SFICORP DOT COM> said:

>Good news! I have been running for a week with rewritten ADSM backup scripts
>and my CPU utilization has not gone above 10% of our 7060-H50. Most of the
>time it's under 5%. I rewrote my daily ADSM backup scripts to remove the
>parameter "wait=yes". I had to break the scripts up to do one command in each
>and check for the completion of the previous task before issuing another
>command or running another script, but it worked!! I am willing to send copies
>of the scripts I am running to you if requested. Neither I nor my company are
>warranting them but you are free to adapt them to your needs.



>Darlene E. Wnukowski
>Lead Systems Programmer
>Schreiber Foods, Inc.
>darlene AT sficorp DOT com
>920-455-6268





>**************************************************************

>This email and any files transmitted with it are confidential
>and intended solely for the use of the individual or entity
>to whom they are addressed. If you have received this email
>in error please notify Postmaster AT sficorp DOT com.

>This footnote also confirms that this email message has been
>swept by MIMEsweeper for the presence of computer viruses.

>**************************************************************

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
=========================================================================