Direct links to fixes
8.1.12.100-IBM-SPCMS-WindowsX64
8.1.12.100-IBM-SPCMS-WindowsI32
8.1.12.100-IBM-SPCMS-Linuxx86_64
8.1.12.100-IBM-SPOC-WindowsX64
8.1.12.100-IBM-SPOC-Linuxx86_64
8.1.12.100-IBM-SPOC-Linuxs390x
8.1.12.100-IBM-SPOC-LinuxPPC64le
8.1.12.100-IBM-SPOC-AIX
8.1.12.100-IBM-SPSRV-WindowsX64
8.1.12.100-IBM-SPSRV-Linuxx86_64
8.1.12.100-IBM-SPSRV-Linuxs390x
8.1.12.100-IBM-SPSRV-Linuxppc64le
8.1.12.100-IBM-SPSRV-AIX
IBM Spectrum Protect Server V8.1.12.X interim fix downloads
IBM Spectrum Protect Server V8.1 Fix Pack 13 (V8.1.13) Downloads
APAR status
Closed as program error.
Error description
After upgrading to 8.1.12, the server could fail to start with the following symptom: ANR9999D_4269667813 AdmSetupAdminSQL(adminit.c:9330) Thread<1>: Error 4208 creating table RETSETSIT. ANR9999D Thread<1> issued message 9999 from: ANR9999D Thread<1> 0x0000000100037c00 StdPutText ANR9999D Thread<1> 0x0000000100038e6c OutDiagToCons ANR9999D Thread<1> 0x000000010000d028 outDiagfExt ANR9999D Thread<1> 0x0000000100f14434 AdmSetupAdminSQL ANR9999D Thread<1> 0x0000000100182bb4 IPRA.$StartServer ANR9999D Thread<1> 0x0000000100181660 admStartServer ANR9999D Thread<1> 0x0000000100001780 main ANR9999D_4269667813 AdmSetupAdminSQL(admi This can happen if the server was used at an 8.1.9.xxx ( where xxx can be any value including 0) server level. It does not matter what level was upgraded from, only if the server at one time was used at an 8.1.9.xxx level. The admin command SHOW VERSIONHISTORY can be used to determine if the server was ever used at that maintenance level. If the server is not running due to the upgrade this can be checked with: db2 "select * from tsmdb1.db_info" Here is a sample line showing an 8.1.9 level: 2020/04/23 05:20:45 08,01,09,300,000,201011214 100 IBM Spectrum Protect versions affected: IBM Spectrum Protect Server 8.1.12 on all supported platforms Initial Impact: Medium Additional Keywords: TS005536416, crash, RETSETSIT
Local fix
The following commands can be used to drop the table that is causing the failure. There is no data loss deleting this table since it is a temporary table. db2start db2 connect to tsmdb1 db2 drop table tsmdb1.retsetsti db2 terminate db2stop NOTE: The table name being dropped is slightly different than the one being created. The one being dropped has an index by the same name as the one being created causing this issue. The table being dropped is an unused temporary table.
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 8.1.12.100 and 8.1.13. Note * * that this is subject to change at the discretion of IBM. * ****************************************************************
Problem conclusion
This problem was fixed. Affected platforms for reported release: AIX, Linux, and Windows. Platforms fixed: AIX, Linux, and Windows.
Temporary fix
Comments
APAR Information
APAR number
IT36777
Reported component name
TSM SERVER
Reported component ID
5698ISMSV
Reported release
81A
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2021-05-04
Closed date
2021-05-06
Last modified date
2021-05-06
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
R81A PSY
UP
R81L PSY
UP
R81W PSY
UP
Document Information
Modified date:
17 December 2021