This is a problem on the client side. The programmer can explain this a LOT
better than I, but it seems that in TSM 4.1.anything the cleanup process
following the archive is bad code. IBM says it's not, but how else do you
explain something that had sub-second response in 3.1.06 now taking from 3
seconds to in an extreme case, 3 minutes in TSM 4.x.x?
Ike Hunley - BCBSFL
-----Original Message-----
From: Kauffman, Tom [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 3:36 PM
To: [EMAIL PROTECTED]
Subject: Re: Archive hangs and Poor Archive Performance at TSM 4.1.2 &
4.2
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:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 1:18 PM
> To: [EMAIL PROTECTED]
> 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
>
Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
affiliate companies are not responsible for errors or omissions in this e-mail
message. Any personal comments made in this e-mail do not reflect the views of Blue
Cross Blue Shield of Florida, Inc.
