ADSM-L

Re: Archive hangs and Poor Archive Performance at TSM 4.1.2 & 4.2

2001-09-21 15:48:57
Subject: Re: Archive hangs and Poor Archive Performance at TSM 4.1.2 & 4.2
From: "Kauffman, Tom" <KauffmanT AT NIBCO DOT COM>
Date: Fri, 21 Sep 2001 14:36:04 -0500
Could someone refresh my memory on this -- is this a server problem, a
client problem, or both?

I'm currently running 3.7.4 as a server, and a mixed bag of 2.x and 3.x
clients. I'll be upgrading the server to 4.x next month (haven't decided on
4.1.4.1 or 4.2.0.1 yet) and figured on doing the clients afterward.

But quite a bit of my daily processes depend on archiving, and I've no
intention of spending my time working around a broken product. If it's a
client problem I can hold off indefinitely; if it's a server problem, I need
to decide if I want to run without support (not a hard decision - I've only
had one support call on 3.7, and that was the empty tape with something
still on it problem others have run into).

Tom Kauffman
NIBCO, Inc

> -----Original Message-----
> From: Richard Sims [mailto:rbs AT BU DOT EDU]
> Sent: Friday, September 21, 2001 1:18 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Archive hangs and Poor Archive Performance at TSM 4.1.2 &
> 4.2
>
>
> >The answer we've received is move to TSM 4.2 using the
> filelist option.
> >Filelist will combine numerous archives in one archive
> session so that the
> >cleanup process is not invoked as much.
> >
> >We can't say we're happy about having to re-write something
> that use to work
> >GREAT in release 3.1.06 and the ONLY thing changing is a
> release of the same
> >product.
>
> That's the kind of recommendation one usually gets only as a
> circumvention.
> The performance problem is conspicuously real, and Tivoli
> should be providing
> a fix for it, as the client software should never have gotten
> out in that
> condition, given proper testing.  At a minimum there should
> be an advisory in
> the client Readme file about the problem, but I see nothing
> there.  This is
> not being handled well.
>
>    Richard Sims, BU
>