Andy,
We are having the problem as well. Thanks for the update. This issue, in
addition to "-clusternode=yes invalid" being reported as an error on our
new Win2k cluster when it shouldn't be, is keeping me from upgrading my
clients from 3.7.2. Our NT Admins are already annoyed by the fact that you
can't click on the gray box to select a directory for restore on our NT
cluster boxes. With the political climate being what it is here, I don't
want to tell them "the good news is we fixed one quirk. but now we have a
new one you need to know about".
I know Tivoli has been hammered pretty hard about quality control on this
listserv, but you guys need to know that it's tough for big TSM supporters
like me to make a case for continued use of TSM with little quirks like
these at nearly every maintenance level. I've hit them in many of the NT
client levels in particular. Those that would prefer to use alternate
backup products at my company ask the question "if we can't even select a
directory during a relatively small restore or get an accurate elapsed time
for a backup, how can we be sure that when it becomes time to do major
recoveries with TSM that it will be up to the job"? Their words not mine.
My 2 cents for what it's worth..
Thanks
Jeff Connor
Niagara Mohawk Power Corp
Andy Raibeck <Andrew_Raibeck AT TIVOLI DOT COM>@VM.MARIST.EDU> on 03/26/2001
10:56:17 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: 4.1.2.12 Client Reporting Erroneous Elapsed Processing Time
Hi Anne,
This is a known defect, and is documented in APAR IC29212. I don't have an
ETA for an available fix, though.
So sorry for the "fuzzy math".
Regards,
Andy
Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
e-mail: araibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."
"Short, Anne" <anne.short AT LMCO DOT COM>@VM.MARIST.EDU> on 03/26/2001 08:35:11
AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: 4.1.2.12 Client Reporting Erroneous Elapsed Processing Time
Anybody else notice this? Since the upgrade to TSM Client to version
4.1.2.12 on our NT 4.0 nodes, the elapsed time for our backups is getting
reported wrong. The particular node I've documented below starts its
backup
at 8:00 pm (and yes, I've verified it's starting on time). You'll notice,
that starting on 03/22/2001, the "Elapsed processing time" is getting
reported to be 3 hours or less even though the backup isn't finishing until
well past 2:00 am. Perhaps its only reporting the elapsed processing time
for the last session that starts, as we let this client run multiple
sessions.
03/22/2001 03:12:19 ANE4964I (Session: 7873, Node: GBNF01) Elapsed
processing time: 00:03:33
03/23/2001 03:14:04 ANE4964I (Session: 9582, Node: GBNF01) Elapsed
processing time: 00:00:44
03/24/2001 04:07:38 ANE4964I (Session: 840, Node: GBNF01) Elapsed
processing time: 00:02:11
03/25/2001 02:20:52 ANE4964I (Session: 1753, Node: GBNF01) Elapsed
processing time: 00:03:38
03/26/2001 02:26:19 ANE4964I (Session: 3168, Node: GBNF01) Elapsed
processing time: 00:00:57
Before the upgrade (version 3.7.2), the elapsed processing time was getting
reported correctly:
03/14/2001 03:16:18 ANE4964I (Session: 329, Node: GBNF01) Elapsed
processing time: 07:15:18
03/16/2001 02:36:29 ANE4964I (Session: 361, Node: GBNF01) Elapsed
processing time: 06:35:25
Considering we get measured on getting all our backups completed within an
8
hour window, I shouldn't complain as this new math will certainly make us
look good!! :-) But, I guess I'll report it as a bug to Tivoli.
Anne Short
Lockheed Martin Enterprise Information Systems
Gaithersburg, Maryland
301-240-6184
CODA/I Storage Management
|
