Direct links to fixes
8.1.2.000-IBM-SPSRV-AIX
8.1.2.000-IBM-SPSRV-Linuxppc64le
8.1.2.000-IBM-SPCMS-Linuxx86_64
8.1.2.000-IBM-SPCMS-WindowsI32
8.1.2.000-IBM-SPSRV-Linuxs390x
8.1.2.000-IBM-SPCMS-WindowsX64
8.1.2.000-IBM-SPSRV-Linuxx86_64
8.1.2.000-IBM-SPSRV-WindowsX64
8.1.2.000-IBM-SPOC-AIX
8.1.2.000-IBM-SPOC-LinuxPPC64le
8.1.2.000-IBM-SPOC-Linuxs390x
8.1.2.000-IBM-SPOC-Linuxx86_64
8.1.2.000-IBM-SPOC-WindowsX64
IBM Spectrum Protect Operations Center V8.1.2 Download
IBM Spectrum Protect Server V8.1 Fix Pack 2 (V8.1.2) Downloads
IBM Spectrum Protect Server V7.1 Fix Pack 8 (7.1.8.000) Downloads
APAR status
Closed as program error.
Error description
The Operations Center flags a directory container storage pool as having a status of critical. Common reasons for a directory storage pool appearing as critical in the OC are: 1) Damaged extents exist in the storage pool. Query damaged output rom an Admin command line shows damaged extents in the storage pool. 2) Storage pool directories and/or their containers within a storage pool are flagged as critical. Drilling down in the OC storage pool panels will show what stgpooldir and/or containers are critical. Following the above details should lead to a fixing action with is usually an audit container at some level. The flagging of the storage pool as critical being addressed by this APAR is neither of the above two cases. A DB2 select against the sd_dedup_audit table results in an entry (or entries) that show a RECOVERYSTATUS of 3: db2 "select * from SD_Dedup_Audit" POOLID 4 TYPE 1 ID 126348669 SOURCE 2 DATEFOUND 2017-03-14-18.57.54.000000 AUDITDATE 2017-03-14-18.57.54.000000 RECOVERYMODE 0 RECOVERYSTATUS 3 RECOVERYID 126348669 Since this extent has been recovered it should not be triggering a status of critical for the pool in which is resides. This APAR will address the OC flagging of the storage pool as critical in this situation where it should not be. Tivoli Storage Manager Versions Affected: All platforms 7.1.3 and above. Initial Impact: Low Additional Keywords: SDDA TSM IBM Spectrum Protect
Local fix
Using the POOLID from the entry(s) in the sd_dedup_audit table run the following DB2 select after first ensuring a current full server database backup exists: db2 "delete from sd_dedup_audit sdda where sdda.poolid=<ssda pool id> and (sdda.id not in (select sdac.chunkid from sd_all_chunks sdac where sdac.poolid=<ssda pool id>) OR sdda.recoverystatus=3)"
Problem summary
**************************************************************** * USERS AFFECTED: * * All Tivoli Storage Manager server and IBM Spectrum Protect * * server users. * **************************************************************** * PROBLEM DESCRIPTION: * * See error description. * **************************************************************** * RECOMMENDATION: * * Apply fixing level when available. This problem is currently * * projected to be fixed in levels 7.1.8 and 8.1.2. Note that * * this is subject to change at the discretion of IBM. * ****************************************************************
Problem conclusion
This problem was fixed. Platforms fixed: AIX, Solaris, Linux, and Windows.
Temporary fix
Comments
APAR Information
APAR number
IT20687
Reported component name
TSM SERVER
Reported component ID
5698ISMSV
Reported release
71W
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-05-19
Closed date
2017-05-30
Last modified date
2017-06-07
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
Document Information
Modified date:
01 September 2023