ADSM-L

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

2002-09-01 05:14:43
Subject: Re: tsm client is down-level with this server version
From: Mark Stapleton <stapleto AT BERBEE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 31 Aug 2002 23:54:30 -0500
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Roger Deschner
> 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.

Sounds to me like you need an SLA that stipulates what happens when people
backgrade *anything*. Something in the realm of "expect problems" and "no
time limit on fixing things"...

> 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.

*sigh* ...and another patch on the SLA that voids your responsibility when
the user does something that none too bright.

> 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.

If I had a script that I was told would either fix everything or destroy the
database, I'd have to put that puppy back in its box and say, "No, thank
you."

Every TSM environment is different (often radically so). It's a very complex
piece of software, and, being almost infinitely configurable, is also almost
infinitely capable of destruction.

You're a better man than I, Gunga Din. I wouldn't work in an academic shop
for any amount of money.

--
Mark Stapleton (stapleton AT berbee DOT com)
Certified TSM consultant
Certified AIX system engineer
MCSE

<Prev in Thread] Current Thread [Next in Thread>