IC87387: DO NOT RUN "REPAIR OCCUPANCY" UTILITY FOR A DISK STORAGE POOL UNTIL THE FIXING LEVEL HAS BEEN APPLIED

APAR status

• Closed as program error.

Error description

• Running the REPAIR OCCUPANCY command over a disk storage pool
  before having upgraded the Tivoli Storage Manager server to at
  least 6.1.5.102, 6.2.3.100 or 6.3.0.0 may create some
  discrepancy.
  
  One of the symptoms without the APAR being applied would be an
  error 1114 during deletion from "DF.MigrCandidates":
  
  ANR2017I Administrator <ADMIN> issued command: DELETE FILESPACE
  <NODE> 11 NAMETYPE=FSID TYPE=ANY DATA=ANY
  ANR0984I Process 2 for DELETE FILESPACE started in the
  BACKGROUND at 14:46:51.
  ANR0800I DELETE FILESPACE <FILESPACENAME> (fsId=11) for node
  <NODE> started as process 2.
  ANR0802I DELETE FILESPACE <FILESPACENAME> (fsId=11)
  (backup/archive data) for node <NODE> started.
  ANR0104E dftxn.c(877): Error 1114 deleting row from table
  "DF.MigrCandidates".
  ANR1181E dftxn.c(227): Data storage transaction 0:618 was
  aborted.
  ANR2183W imfsdel.c(2925): Transaction 0:618 was aborted.
  ANR0826I DELETE FILESPACE <FILESPACENAME> for node <NODE>
  encountered a transaction failure.
  ANR0827I DELETE FILESPACE <FILESPACENAME> (fsId=11) will be
  retried for node <NODE>.
  
  
  From a DFTXN trace you could see something like
  08:51:29.054
  [50][dftxn.c][803][PrepareClusters]:PrepareClusters: Deleting
  row for pool 4, ck1 2, ck2: 11
  08:51:29.054
  [50][dftxn.c][828][PrepareClusters]:PrepareClusters: Current
  values: numFiles: 35, numChunks: 0, migOcc: 34488320, logOcc:
  34488320, rptOcc: 34488320
  08:51:29.054 [50][output.c][7271][PutConsoleMsg]:ANR0104E
  dftxn.c(877): Error 1114 deleting row from table
  "DF.MigrCandidates".~
  
  ck2 represents the filespace id, so if you look at
  db2 select * from tsmdb1.df_clusters order by poolid, ck1, ck2
  db2 select * from tsmdb1.DF_MigrCandidates order by poolid, ck1,
  ck2
  
  shows DF_MigrCandidates occupancy record is not sync with the
  DF_CLUSTERS for the filespace to be deleted.
  
  Query: db2 select * from tsmdb1.df_clusters order by poolid,
  ck2, ck2
  
  POOLID      SRVID       CK1         CK2         NUMFILES
  OCCUPANCY            ..
  ----------- ----------- ----------- ----------- -----------
  -------------------- ..
            4           0           2          11          35
  34488320 ..
  
  Query: db2 select * from tsmdb1.DF_MigrCandidates order by
  poolid, ck1, ck2
  POOLID      OCCUPANCY            SRVID       CK1         CK2
  ----------- -------------------- ----------- -----------
  -----------
            4               917504           0           2
  11
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Tivoli Storage Manager Versions Affected:
  Tivoli Storage Manager Server V6
  
  
  Initial Impact:
  Medium
  
  
  Additional Keywords:
  TSM REPAIR OCCUPANCY DISK STGPOOL UPGRADE DISCREPANCY
  

Local fix

• Don't run the repair occupancy for DISK storage pool until the
  fixing level have been applied.
  
  If you face the error 1114 as reported above, you can submit the
  following DB2 commands as instance owner to fix the
  inconsistency:
  db2 connect to tsmdb1
  db2 update tsmdb1.DF_MigrCandidates dfmc set dfmc.OCCUPANCY =
  (select dfcl.occupancy from tsmdb1.df_clusters dfcl where
  dfcl.srvid=dfmc.srvid and dfcl.poolid=dfmc.poolid and
  dfcl.ck1=dfmc.ck1 and dfcl.ck2=dfmc.ck2)
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Tivoli Storage Manager server users of   *
  *                 the REPAIR OCCUPANCY utility.                *
  ****************************************************************
  * PROBLEM DESCRIPTION: See ERROR DESCRIPTION.                  *
  ****************************************************************
  * RECOMMENDATION: Apply fixing level when available.           *
  *                 This problem is currently projected to be    *
  *                 fixed in levels 6.2.5 and 6.3.4.             *
  *                 Note that this is subject to change at       *
  *                 the discretion of IBM.                       *
  ****************************************************************
  *
  
  AFFECTED PLATFORMS:
  AIX, HP-UX, Solaris, Linux, and Windows.
  

Problem conclusion

• The described problem has been resolved.
  

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:

Fix information

• Fixed component name

  TSM SERVER

• Fixed component ID

  5698ISMSV

Applicable component levels

• R62A PSY

     UP

• R62H PSY

     UP

• R62L PSY

     UP

• R62S PSY

     UP

• R62W PSY

     UP

• R63A PSY

     UP

• R63H PSY

     UP

• R63L PSY

     UP

• R63S PSY

     UP

• R63W PSY

     UP