IC47529: TSM 5.3 FILE DEVCLASS OPERATIONS CREATE VOLS WITH LOW UTIL%, CAUSING LARGE NUMBER OF VOLS AND MEDIAWAIT DURING BACKUP

APAR status

• Closed as program error.

Error description

• In some cases, the TSM Server may not choose the
  optimal output volume in a file devclass.  These
  symptoms can occur when no scratch volumes are
  available and TSM is selecting a volume to use from the
  filling volumes.  When TSM attempts to acquire a mount
  point in a file devclass, TSM may mistakenly select a
  filling volume that is currently being written to when
  another filling volume is available to satisfy the
  request.  This can cause processes, and/or sessions, to
  enter a MEDIAWAIT state. This MEDIAWAIT state can
  impact overall performance of the TSM Server.  The TSM
  Server should be modified to use eligible filling
  volumes before entering MEDIAWAIT in these cases.
  
  This problem can also cause migration to kick off unexpectedly
  for a FILE stgpool.  Many volumes with low utilization will be
  seen in the Q VOL output.  These volumes with very low Pct Util
  will be left in a Filling status, but will not be written to
  again during the backup process.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: Customers running TSM 5.3, who are using     *
  *                 the DEVTYPE=FILE device class, when there    *
  *                 are multiple clients attempting to write     *
  *                 data to a storage pool using this devclass.  *
  ****************************************************************
  * PROBLEM DESCRIPTION: In TSM 5.3, under the following         *
  *                      conditions:  1) using the DEVTYPE=FILE  *
  *                      device class, 2) all scratch volumes    *
  *                      are exhausted, 3) when the MOUNTLIMIT   *
  *                      parameter in said deviceclass is        *
  *                      sufficiently high, 4) when there are    *
  *                      multiple clients attempting to write    *
  *                      data to a storage pool using said       *
  *                      devclass.  Under these conditions,      *
  *                      the MOUNTLIMIT parameter on the         *
  *                      devclass may be ignored, a small        *
  *                      number of file volumes is mounted       *
  *                      and some client sessions go into        *
  *                      media wait on the mounted file          *
  *                      volumes instead of mounting other       *
  *                      filling volumes.  This causes a         *
  *                      performance problem.                    *
  *                                                              *
  *                      A related symptom of this problem is    *
  *                      that if the customer attempts to work   *
  *                      around the problem by defining more     *
  *                      scratch volumes, until the number of    *
  *                      scratch volumes is exhausted, under     *
  *                      some conditions, when a scratch volume  *
  *                      is selected, a small of amount of data  *
  *                      is written to the volume, then the      *
  *                      volume is closed and another scratch    *
  *                      volume is selected to which another     *
  *                      small amount of data is written.        *
  *                      This continues until all scratch        *
  *                      volumes have been exhausted; then       *
  *                      the problem as documented in the        *
  *                      previous paragraph occurs.              *
  ****************************************************************
  * RECOMMENDATION: Apply fixing level when available. This      *
  *                 problem is currently projected to be fixed   *
  *                 in levels 5.3.3 and 5.3.2.2. Note that       *
  *                 this is subject to change at the             *
  *                 discretion of IBM.                           *
  ****************************************************************
  See the Problem Fix section.
  

Problem conclusion

• See the Problem Fix section.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  PK14410

Fix information

• Fixed component name

  TSM SERVER 510

• Fixed component ID

  5698ISMSV

Applicable component levels

• R53A PSY

     UP

• R53H PSY

     UP

• R53L PSY

     UP

• R53S PSY

     UP

• R53W PSY

     UP

• R53Z PSY

     UP