Off-hand, I do not know what the problem could be, at least for the non-4.1.2 nodes. For the 4.1.2 nodes, I would recommend upgrading to the latest client levels (or at least something that is supported. as 4.1 is no longer supported).
For the 4.2 or higher clients: Do the same clients exhibit the problem every time? Some times? Once? Are there any messages in the dsmsched.log or dsmerror.log files that would indicate a problem? how about in the server actlog? I'm not sure if the extracts you included were a complete log of events between the client start and end times, but I suspect not... any client sessions get disconnected or cancelled due to timeouts? Were there any other problems reported? If you have a client that can consistently reproduce the problem, try going to that client machine and running a manual backup against a sizeable directory such that the problem would be obvious if it occurred, i.e.: dsmc i c:\somedir\ -su=y Does the problem exhibit itself when a backup is run manually? If you don't see anything obvious, then you might try upgrading to the 4.2.3 or 5.1.5 client levels (5.1.5.9 for Windows) and see if that helps (I know it's just a shot in the dark, so try one client first to see if that makes a difference). If you *still* see the problem, then you should open a problem report with IBM so that we can look into it in further detail. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] (change eye to i to reply) The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. Dameon White <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 02/28/2003 09:48 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Innaccurate Elapsed Processing Time Sorry about the omitted Subject line. >Andy, > >There are several nodes that are 4.1.2.x that are having >the issues. But, there are also several Win2k nodes with >client code 4.2.2.0 that are also experiencing this issue > >Dameon. > >You do not indicate which version of the TSM client you >are running. This is important, as the elapsed processing >time is being reported to the servr by the client. > >There was a problem back in version 4.1.2 where elapsed >processing time was not being reported correctly (it was >too short, as you are seeing). The APAR number is IC29212. >Maybe this is the problem. You can find more info on this >by going to http://www.ibm.com and entering the APAR >number as a search argument (top of the page). > >Regards, > >Andy > >Andy Raibeck >IBM Software Group >Tivoli Storage Manager Client Development >Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] >Internet e-mail: [EMAIL PROTECTED] (change eye to i to >reply) > >The only dumb question is the one that goes unasked. >The command line is your friend. >"Good enough" is the enemy of excellence. Dameon White <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 02/28/2003 08:59 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: My TSM server is 4.2.3.0 on AIX 4.3.3 I am seeing inaccurate values for elapsed processing time for multiple os platforms, multiple os levels, and multiple tsm client levels. I have included one example. Has anyone else seen similar inaccuracies? If looking to see how long my backup took, I assume I should start disregarding the elapsed processing time that TSM is reporting. Does anyone know of a more accurate place one should find such data? 02/27/03 21:00:02 ANR2561I Schedule prompter contacting filesvr01 (session 36725) to start a scheduled operation. 02/27/03 21:00:03 ANR0406I Session 36726 started for node filesvr01 (HPUX) (Tcp/Ip 10.172.69.2(54195)). 02/27/03 21:00:04 ANR0406I Session 36728 started for node filesvr01 (HPUX) (Tcp/Ip 10.172.69.2(54196)). 02/27/03 21:25:56 ANR0403I Session 36728 ended for node filesvr01 (HPUX). 02/27/03 21:25:58 ANE4952I (Session: 36726, Node: filesvr01) Total number of objects inspected: 62,102 02/27/03 21:25:58 ANE4954I (Session: 36726, Node: filesvr01) Total number of objects backed up: 218 02/27/03 21:25:58 ANE4958I (Session: 36726, Node: filesvr01) Total number of objects updated: 0 02/27/03 21:25:58 ANE4960I (Session: 36726, Node: filesvr01) Total number of objects rebound: 0 02/27/03 21:25:58 ANE4957I (Session: 36726, Node: filesvr01) Total number of objects deleted: 0 02/27/03 21:25:58 ANE4970I (Session: 36726, Node: filesvr01) Total number of objects expired: 1 02/27/03 21:25:58 ANE4959I (Session: 36726, Node: filesvr01) Total number of objects failed: 0 02/27/03 21:25:58 ANE4961I (Session: 36726, Node: filesvr01) Total number of bytes transferred: 109.31 MB 02/27/03 21:25:58 ANE4963I (Session: 36726, Node: filesvr01) Data transfer time: 1,454.74 sec 02/27/03 21:25:58 ANE4966I (Session: 36726, Node: filesvr01) Network data transfer rate: 76.95 KB/sec 02/27/03 21:25:58 ANE4967I (Session: 36726, Node: filesvr01) Aggregate data transfer rate: 72.02 KB/sec 02/27/03 21:25:58 ANE4968I (Session: 36726, Node: filesvr01) Objects compressed by: 0% 02/27/03 21:25:58 ANE4964I (Session: 36726, Node: filesvr01) Elapsed processing time: 00:00:54 02/27/03 21:25:58 ANR2507I Schedule FILESVR_BU for domain DALLAS started at 02/27/03 21:00:00 for node filesvr01 completed successfully at 02/27/03 21:25:58. 02/27/03 21:25:58 ANR0403I Session 36726 ended for node filesvr01 (HPUX). Thanks for your patience as I rant. Dameon