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
