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
7.1.8.000-TIV-TSMSRV-AIX
7.1.8.000-TIV-TSMSRV-HP-UX
7.1.8.000-TIV-TSMSRV-Linuxppc64
7.1.8.000-TIV-TSMSRV-Linuxs390x
7.1.8.000-TIV-TSMSRV-Linuxx86_64
7.1.8.000-TIV-TSMSRV-SolarisSPARC
7.1.8.000-TIV-TSMSRV-WIN
7.1.8.000-TIV-TSMOC-AIX
7.1.8.000-TIV-TSMOC-Linuxx64
7.1.8.000-TIV-TSMOC-Windows
7.1.8.000-TIV-TSMOC-LinuxPPC64
7.1.8.000-TIV-TSMOC-LinuxPPC64le
7.1.8.000-TIV-TSMOC-LinuxS390
IBM Spectrum Protect Server V8.1 Fix Pack 2 (V8.1.2) Downloads
APAR status
Closed as program error.
Error description
When running server versions 7.1.6.x or higher, and 8.1.x, the mount of tape volumes can experience long delays if: 1. Server option 'STATUSMONITOR' is set to on 2. The affected server has many drive paths defined (no specific trigger value). 3. Server option 'STATUSREFRESHINTERVAL' is a low value so that status data is collected at very short intervals. If there is status monitoring already running and a mount is started, the server will see a 'slow down' of that mount because it has to wait for the status monitor step to finish looking up drive paths status (online/offline) . The more paths that are defined, the slower the mount will be. It has been seen in an environment, where mounts went from taking seconds to 7-10 minutes Looking at 'show threads' the following type of examples can be seen to confirm this condition as described: Thread 238, Parent 36: MonGroup1Thread, Storage 42191280, AllocCnt 4776830 HighWaterAmt 42301765 tid=b1ee, ptid=524, det=1, zomb=0, join=0, result=0, sess=0, procToken=0, sessToken=0 Stack trace: 0x09000000001f7210 semop 0x0900000003cf0750 sqloSSemV 0x0900000003e93370 sqlccipcsend__FP17SQLCC_COMHANDLE_TP12SQLCC_COND_T 0x0900000003cead10 sqlccsend 0x0900000003d9b150 sqljcSend__FP10sqljCmnMgr 0x090000000430ec8c sqljrDrdaArFetch__FP14db2UCinterfaceP15db2UCCursorInfo 0x0900000003ca3f5c csmDriveFetch__FP14db2UCinterfaceP15db2UCCursorInfobT3 0x0900000003ca56ac csmGetCursorBuf__FP14db2UCinterfacePPcPUlT3PP11CSM_ROWPOSNT3PvUl Ui 0x09000000043c8ccc CLI_callbDrdaOutput__FP14db2UCinterface 0x0900000003ca08b8 csmFetch__FP14db2UCinterfaceP15db2UCCursorInfo 0x0900000003ff09d8 CLI_sqlFetch__FP17CLI_STATEMENTINFOUllT3PUiPUsP5sqlcaP19CLI_ERRO RHEADERI NFO 0x090000000410cb90 SQLFetch 0x0000000100196bec IPRA.$RdbFetchAndGetNextResponse 0x0000000100192134 tbCliMRFetch 0x00000001004d14f8 naGetNextPath 0x00000001004a011c MmsMonitorLibraryForDevClass 0x0000000100259770 pvrMonitorDevices 0x00000001000ab6d4 StatusMonitorThread 0x000000010000e094 StartThread Holding mutex libP->driveListMutex (0x1120636a8), acquired at mmsdrive.c(7274) Holding mutex NAV->mutex (0x112105dc8), acquired at napthcmd.c(2356) Thread 265, Parent 36: MonTapeDeviceThread, Storage 24585003, AllocCnt 1038187 HighWaterAmt 24697602 tid=be09, ptid=524, det=1, zomb=0, join=0, result=0, sess=0, procToken=0, sessToken=0 Stack trace: 0x000000000000de10 *UNKNOWN* 0x00000001004d1e64 naGetNextPath 0x00000001004a011c MmsMonitorLibraryForDevClass 0x000000010025b21c pvrMonitorTapeDevices 0x00000001000ad1ec StatusMonitorGridsThread 0x000000010000e094 StartThread Holding mutex libP->driveListMutex (0x11246a288), acquired at mmsdrive.c(7274) Holding mutex NAV->mutex (0x111efacc8), acquired at napthcmd.c(2356) . In each example case, the status monitor holds mutex for mmsdrive.c and napthcmd.c and causes the tape mount to slow down. IBM Spectrum Protect versions affected: Server 7.1.6.x and higher, and 8.1.x on all supported platforms Initial Impact: Medium Additional Keywords: TSM IBM Spectrum Protect hang mount wait delay
Local fix
If the affected server is not an Operations Center Hub or Spoke Server: Set STATUSMonitor OFF to disable the status monitor. If the affected server is an Operations Center Hub or Spoke Server: Increase the 'statusrefreshinterval' option to have a higher value than the default 5 minutes setting SET STATUSREFRESHINTERVAL no_of_minutes (possible values for minutes setting is 1 - 2440) so that the status data gathering runs less often.
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 level 8.1.2. 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, HP-US, Solaris, Linux, and Windows.
Temporary fix
Comments
APAR Information
APAR number
IT19593
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
2017-03-08
Closed date
2017-05-09
Last modified date
2017-09-28
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:
11 September 2024