We understand that the archive performance is a real issue, but the
utilities/commands you mention do not necessarily apply in all cases.
There are usually reasons why we do not document certain facilities, one
of which is for the potential loss of data. Since the archive utilities
can be destructive, we have deliberately left them undocumented. In fact,
it is my understanding that we don't even want our level 1 folks to advise
customers to use the utilities. I know that this may seem a bit
overcautious, especially to more experienced TSM users, but we don't want
anyone to get "burned".

With that said, the issue of whether we should document these utilities is
being revisited internally.

I realize that some information on how to use the utilities has already
been posted here. But until we decide to publicly document them, I
strongly recommend that you contact TSM support before attempting to use
them.

Regards,

Andy

Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/22/2001 02:01
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Archive hangs and Poor Archive Performance at TSM 
4.1.2 & 4.2



As already Petr wrote use convert archive. This a half-documented command
-
it is not available (in my) Administrator's Reference but you can find it
it is not available (in my) Administrator's Reference but you can find it
through help as you can see:

tsm: PUMBA.ACIT.BG>help convert arch
CONVERT ARCHIVE
CONVERT ARCHIVE (Allow Clients to Query Archive Files by Description )
Use this command to improve the efficiency of a command line or API client
query of archive files and directories using the description option.
Previously, an API client could not perform an efficient query at all and
a
Version 3.1 or later command line client could perform such a query only
if
the node had signed onto the server from a GUI at least once. Perform this
conversion only once for each node.
A GUI backup-archive client can already do a more efficient query without
this command being issued.

At the same time we have a section in Quick Start manual "Before
Performing
a Migrate Install" but do not have a section "After Performing a Migrate
Install".
I've learned about this command reading the discussion at this mail list.
So Richard is right - this is a real issue to be well documented.
Maybe even the IBM support people contacted by Ike and Holly didn't knew
about this and tried in a wrong direction.

So maybe it is time for people at IBM/Tivoli (Andy, Thiha, Bill ???) to
advise their colleagues this to be included in the docs and readmes. The
impact will be that less people will have problems with the product (which
sometimes causes customer dissatisfaction and loweres the reputation) and
will ease the life of IBM (!!!) support staff.

Thank you for the patience reading this.


Zlatko Krastev
IT Consultant






b290 <bizzorg AT MEDIAONE DOT NET> on 21.09.2001 05:14:11
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

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

I'm trying to find out if anyone out there in TSM land has problems with
Archiving file after upgrading from ADSM 3.1.06 to TSM 4.1.2 & TSM 4.2.

There is an process using macros to build DSMC archive statements to
archive
files.  At ADSM 3.1.06 it ran fine with sub-second response time.  Now
that
TSM 4.anything is installed the best response time we've seen is 3
seconds,
the worst is 41 seconds.  To make matters worse, Archives hang in idle
wait
for no apparent reason.  We've tried to trace this, but when trace is on,
archive stop hanging in idle wait.  It's a problem determination
nightmare.

The response from IBM is to use the TSM 4.2 with the filelist option and
we
are working hard to implement this.

Does anyone have ANY ideas on what we might do to improve performance
while
our EDI techie re-write the process to implement the filelist option?

Any help would be greatly appreciated.  This issue has been outstanding
for
a month now.