The fix for this is at these levels (per apar doc): Apply patch 4.2.2.5, 5.1.1.1 or higher, available through Tivoli Web Page to resolve this problem, or fixing PTF when available.
Here's a blerb from my etr/pmr (problem ticket): The APAR you are referring to is IC34462. This issue is specific to the summary table not being updated when client sessions are severed and the session has to be re-established. This APAR is currently open, but I have added you to the interested parties list for this APAR. There was also another APAR (IC33455) which addressed an issue with the summary table simply not being updated properly during client backups. Here's the actual 2 apars...the doc on the problem/issue: FYI Thanks Tim APAR Identifier ...... IC34462 Last Changed..02/09/19 BYTES FIELD IN SUMMARY TABLE SHOWS VALUE 0 IF THE BACKUP SESSION IS LOST AND THEN REOPENED AGAIN (I.E. MSG ANS1809E) Symptom ...... IN INCORROUT Status ........... OPEN Severity ................... 2 Date Closed ......... Component .......... 5698ISMSV Duplicate of ........ Reported Release ......... 51A Fixed Release ............ Component Name TSM SERVER 510 Special Notice Current Target Date .. Flags SCP ................... AIXRSC Platform ............ AIX Status Detail: Not Available PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: When a backup session is lost and then reopened again successfully (e.g. MSG ANS1809E can be seen in the dsmsched.log), not all values in the SUMMARY TABLE of the TSM server will show the correct backup statistics. The BYTES field shows in that case a value of 0, while e.g the fields EXAMINED and AFFECTED show correct values. . Example: ======== 1.) select * from summary where activity='BACKUP': START_TIME: 2002-08-28 19:32:06.000000 END_TIME: 2002-08-28 19:54:17.000000 ACTIVITY: BACKUP NUMBER: 366 ENTITY: LWLSAP2 COMMMETH: Tcp/Ip ADDRESS: 172.20.13.42:33133 SCHEDULE_NAME: MO-FR-1800 EXAMINED: 71137 AFFECTED: 251 FAILED: 0 BYTES: 0 <= | IDLE: 0 MEDIAW: 0 PROCESSES: 1 SUCCESSFUL: YES VOLUME_NAME: DRIVE_NAME: LIBRARY_NAME: LAST_USE: . 2.) dsmsched.log: 08/28/02 18:01:25 Scheduler has been started by Dsmcad. 08/28/02 18:01:25 Querying server for next scheduled event. 08/28/02 18:01:25 Node Name: LWLSAP2 ... 08/28/02 18:59:19 ANS1898I ***** Processed 66,000 files ***** 08/28/02 19:31:50 Normal File--> 2,048,008,192 /oracle/09p2/daten6/TBS_APOLLO4_IMG_TBS_2.ora Sent 08/28/02 19:31:50 ANS1809E Session is lost; initializing session reopen procedure. 08/28/02 19:32:06 ... successful 08/28/02 19:32:09 ANS1898I ***** Processed 66,500 files ***** ... 08/28/02 19:54:16 Total number of objects inspected: 71,137 08/28/02 19:54:16 Total number of objects backed up: 251 08/28/02 19:54:16 Total number of objects updated: 0 08/28/02 19:54:16 Total number of objects rebound: 0 08/28/02 19:54:16 Total number of objects deleted: 0 08/28/02 19:54:16 Total number of objects expired: 63 08/28/02 19:54:16 Total number of objects failed: 0 08/28/02 19:54:16 Total number of bytes transferred: 6.46 GB 08/28/02 19:54:16 Data transfer time: 1,868.07 sec 08/28/02 19:54:16 Network data transfer rate: 3,629.75 KB/sec 08/28/02 19:54:16 Aggregate data transfer rate:1,001.56 KB/sec 08/28/02 19:54:16 Objects compressed by: 19% 08/28/02 19:54:16 Elapsed processing time: 01:52:50 ################################################################ It seems that when a session is lost and then reopened again, the new session descriptor does not hold the value for the bytes transfered so far anymore. . This problem was seen on a TSM AIX and NT 5.1.1.4 server, but maybe all TSM server levels will be affected which inlcude the fix for APAR IC33455. . Recreation: Unplug the network cable during a backup session => session lost Plug the network cable in again => backup session restarts Then check the SUMMARY TABLE for the BYTES field LOCAL FIX: Do not believe the values reported in the SUMMARY TABLE. Check the DSMSCHED.LOG or the ACTLOG for the correct backup statistics. APAR Identifier ...... IC33455 Last Changed..02/07/19 SUMMARY TABLE NOT BEING FULLY UPDATED Symptom ...... IN INCORROUT Status ........... CLOSED PER Severity ................... 2 Date Closed ......... 02/06/07 Component .......... 5698TSMAX Duplicate of ........ Reported Release ......... 420 Fixed Release ............ 999 Component Name TSM AIX SERVER Special Notice Current Target Date .. Flags SCP ................... AIXRSC Platform ............ AIX Status Detail: Not Available PE PTF List: PTF List: Release 420 : PTF not available yet Parent APAR: Child APAR list: PQ62875 IC34044 IC34045 IC34046 PQ62876 IC34047 ERROR DESCRIPTION: Found on TSM Version 4.2.2.0 Other Versions Affected TSM Server V5.1 OSs Effected All (recreated on WIN, AIX, Solaris) Happens with all TSM Client levels (tested 4.x thru 5.1 clients Impact: medium When backing up to a V4.2..2.0 or V5.1.0 TSM server the summary table is not being updated to show the correct amount of bytes received. In the older versions of the server the bytes would display the amount of data received,however with versions 5.1.0 and 4.2.2.0 the bytes received is reflecting 0 bytes. This is a problem for customers that verify backups with scripts querying the SUMMARY table: .. "select * from SUMMARY where ACTIVITY = 'BACKUP' " .. Examples: Server Version 4, Release 2, Level 1.11 Total number of bytes transferred: 8.55 MB tsm: SOCRATES>select * from SUMMARY where ACTIVITY = 'BACKUP' START_TIME: 2002-04-29 14:42:49.000000 END_TIME: 2002-04-29 14:44:06.000000 ACTIVITY: BACKUP NUMBER: 3 ENTITY: CHIPSHOT COMMMETH: Tcp/Ip SCHEDULE_NAME: EXAMINED: 54 AFFECTED: 54 FAILED: 0 BYTES: 0 IDLE: 76 MEDIAW: 0 PROCESSES: 1 SUCCESSFUL: YES VOLUME_NAME: DRIVE_NAME: LIBRARY_NAME: LAST_USE: Server Version 4, Release 2, Level 2.0 Total number of bytes transferred: 6.73 MB tsm: DUMPTRUCK>select * from SUMMARY where ACTIVITY='BACKUP' *** Older Backup when TSM server was at V4.2.1.0 ** START_TIME: 2002-04-15 15:18:57.000000 END_TIME: 2002-04-15 15:20:55.000000 ACTIVITY: BACKUP NUMBER: 5 ENTITY: COSMO COMMMETH: Tcp/Ip SCHEDULE_NAME: EXAMINED: 459 AFFECTED: 459 FAILED: 0 BYTES: 10195527 IDLE: 0 MEDIAW: 0 PROCESSES: 1 SUCCESSFUL: YES VOLUME_NAME: DRIVE_NAME: LIBRARY_NAME: LAST_USE: *********After Upgrade to V4.2.2*************** START_TIME: 2002-04-29 14:59:42.000000 END_TIME: 2002-04-29 15:03:25.000000 ACTIVITY: BACKUP NUMBER: 2 ENTITY: CHIPSHOT COMMMETH: Tcp/Ip SCHEDULE_NAME: EXAMINED: 74 AFFECTED: 74 FAILED: 0 BYTES: 0 IDLE: 222 MEDIAW: 0 PROCESSES: 1 SUCCESSFUL: YES VOLUME_NAME: DRIVE_NAME: LIBRARY_NAME: LAST_USE: LOCAL FIX: Keywords: ADAS_BYTES_AFFECTED multi-threaded client This also effects statistics of "ARCHIVE" sessions. . Apply patch 4.2.2.5, 5.1.1.1 or higher, available through Tivoli Web Page to resolve this problem, or fixing PTF when available. PROBLEM SUMMARY: **************************************************************** * USERS AFFECTED: All Platforms of TSM Server version 4.2.2.X * * All Platforms of TSM Server version 5.1.0.X * * All Platforms of TSM Server version 5.1.1.0 * **************************************************************** * PROBLEM DESCRIPTION: When backing up to a V4.2.2.0 or * * V5.1.0 TSM server the * * summary table is not being updated to * * show the correct amount * * of bytes received. * **************************************************************** * RECOMMENDATION: Apply fixing PTF or Patch. * **************************************************************** This is a problem for customers that verify backups with scripts querying the SUMMARY table: .. "select * from SUMMARY where ACTIVITY = 'BACKUP' " PROBLEM CONCLUSION: Server has been modified. Summary table is not being updated to show the correct amount of bytes received. TEMPORARY FIX: COMMENTS: MODULES/MACROS: NONE SRLS: NONE RTN CODES: CIRCUMVENTION: MESSAGE TO SUBMITTER: