Direct links to fixes
8.1.1.100-IBM-SPOC-WindowsX64
8.1.1.100-IBM-SPOC-Linuxx86_64
8.1.1.100-IBM-SPOC-Linuxs390x
8.1.1.100-IBM-SPOC-AIX
8.1.1.000-IBM-SPSRV-WindowsX64
8.1.1.000-IBM-SPSRV-Linuxs390x
8.1.1.000-IBM-SPSRV-AIX
8.1.1.000-IBM-SPSRV-Linuxx86_64
7.1.7.100-TIV-TSMSRV-WIN
7.1.7.100-TIV-TSMSRV-SolarisSPARC
7.1.7.100-TIV-TSMSRV-Linuxx86_64
7.1.7.100-TIV-TSMSRV-Linuxs390x
7.1.7.100-TIV-TSMSRV-Linuxppc64
7.1.7.100-TIV-TSMSRV-HP-UX
7.1.7.100-TIV-TSMSRV-AIX
IBM Spectrum Protect Server V8.1 Fix Pack 1 (V8.1.1) Downloads
IBM Spectrum Protect Server V7.1.7.X interim fix downloads
IBM Spectrum Protect Server V7.1 Fix Pack 8 (7.1.8.000) Downloads
APAR status
Closed as program error.
Error description
When running an AUDIT CONTAINER with ACTION=REMOVEDAMAGED and FORCEORPHANDBDEL=YES, all of the cloud orphaned objects should be removed from the IBM Spectrum Protect server database, even if they can't be deleted from the cloud. However, in 7.1.6 and above, the failed deletions end up resulting in those objects being added back into the database in the sd_cloud_orphaned table. This goes against the intended behavior of the FORCEORPHANDBDEL parameter. The impact of this is that when there are scenarios of the object storage target of a storage pool being disconnected, there is no way to delete the chunks from the database that are recorded as being in the object storage without going directly to DB2. Customer/L2 Diagnostics: Run "SHOW DAMAGED <stgpoolname>" before and after running AUDIT CONTAINER with ACTION=REMOVEDAMAGED and FORCEORPHANDBDEL=YES. These results will still show orphaned extents after the audit, and review of the dsmffdc.log will show Java deletion errors. Depending upon the exact nature of the situation these errors in the ffdc log may look something like: [ FFDC_GENERAL_SERVER_ERROR ]: (sdcloud.c:3244) com.tivoli.dsm.cloud.api.ProviderS3 handleException com.amazonaws.AmazonClientException Unable to execute HTTP request: Connect to 9.11.60.111:80 [/9.11.60.111] failed: Connection refused: connect OR [ FFDC_GENERAL_SERVER_ERROR ]: (sdcloud.c:3244) com.tivoli.dsm.cloud.api.ProviderS3 handleException com.amazonaws.services.s3.model.AmazonS3Exception Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: 0ea65a63-c451-49eb-83c9-803cc8d303c1) HTTP Status Code: 403 Tivoli Storage Manager Versions Affected: 7.1.6 and above on all platforms Initial Impact: Low Additional Keywords: TSM IBM Spectrum Protect
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * All 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.7.100, 7.1.8, and 8.1.1. * * Note that this is subject to change at the discretion of * * IBM. * ****************************************************************
Problem conclusion
This problem was fixed. Affected platforms for reported release: AIX, HP-UX, Solaris, Linux, and Windows. Platforms fixed: AIX, Linux, and Windows.
Temporary fix
Comments
APAR Information
APAR number
IT18444
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
2016-12-15
Closed date
2016-12-19
Last modified date
2016-12-19
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
R71A PSY
UP
R71H PSY
UP
R71L PSY
UP
R71S PSY
UP
R71W PSY
UP
R81A PSY
UP
R81L PSY
UP
R81W PSY
UP
Document Information
Modified date:
26 September 2021