ADSM-L

Re: tsm client is down-level with this server version

2002-08-29 13:16:24
Subject: Re: tsm client is down-level with this server version
From: Andy Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 29 Aug 2002 13:07:27 -0400
>>
Would it be possible to provide a safe and tested script, or an APAR
that introduces a new secret command, that can untangle this mess in
some automated way? The current method of fixing it is way too costly.
<<

Coincidentally, I just had that conversation with one of our server
developers, and they will look into doing this (no commitment right now,
but the odds are pretty good).

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (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.




Roger Deschner <rogerd AT UIC DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/29/2002 09:03
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: tsm client is down-level with this server version



We've got half a dozen clients stuck like this right now. The first case
I had was an important, tenured, and extremely impatient professor who
had converted from Win 98 to Win XP, decided that XP "stinks", and
wanted to format his hard drive and restore his comfortable old Win 98
system from ITSM. (This is what backup is for, right?) Because this was
basically a point-in-time restore, deleting the node was not a possible
strategy. He was incredulous that it took me several days of
communication with IBM support to straighten it out and peppered me with
emails demanding that I work faster on it the whole time I was
exchanging special commands and their outputs.

The second was an aggressively confused user who was backing up two
computers using one node, and who thereby un-did the fix mere hours
after I had spent several hours with IBM Support fixing it. I refused to
fix it again for this user and made their node restore-only until I
communicated with their supervisor about our one computer per node
policies.

I have not even begun to figure out the rest, because I know it is a
huge black hole for my time. Before I even call Support, I've got to
reach each end-user and figure out how they caused this, to insure that
they don't inadvertently un-do it after we (me and Support) spend
several hours fixing it.

Those who would want to try the solution on their own are misguided; it
cannot be done - Andy Raibeck is absolutely correct in this regard. You
must call Tivoli Support, but while they will be able to help, it will
be a lengthly and complicated process. Budget several hours per case.
And type carefully!!!

I really wish the existence of a correcting APAR was made more public.
I'm going to install it soon (today!), but I'll still have those half
dozen clients who appear to have "unicode cooties" to untangle.

Would it be possible to provide a safe and tested script, or an APAR
that introduces a new secret command, that can untangle this mess in
some automated way? The current method of fixing it is way too costly.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu