Hello,
the way directories and files are restored has changed a while back.
There is no need to first restore the directories and then the files as
stated
below. This restore order is described in apar IC24321. I have included
the text of that apar here below :

"During ADSM restore and/or retrieve processing the objects
being restored/retrieved are being returned from the server to
the client in "restore order". This concept of "restore order"
is that the objects are returned in the order on which they
appear on the given media. This avoids restore/retrieve
performance issues of sequential volume "thrashing" (positioning
back and forth on a sequential volume) and multiple mounts of
the same sequential media. The "restore order" considers where
objects exists on sequential media and brings them back in this
order so that the media can be moved from beginning to end. One
of the side effects of this type of processing involves the
restore/retrieve of directories. When a file needs to be
restored/retrieved into a directory that does not exist yet
(because its restore order is down further) the ADSM client must
build a skeleton directory to place this file under. When the
client then encounters the directory in the restore order it
will overwrite this skeleton it originally put down. At this
time the ADSM client is not designed to track which directories
it lays down as skeletons and which were already this. This
means that the client restore/retrieves directories whenever
it encounters them within the restore order. This is true
regardless of replace=no being specified. Or regardless of
-ifnewer being used and the directory being restored being
older. The ADSM client needs a design change in this area to
older. The ADSM client needs a design change in this area to
track which directories it puts down as skeletons and which it
does not. It needs to only restore those where it put down the
skeleton."


Thought you'd be interested to know about this.

Have a great day !

-----------------------------------------------------------------
Rejean Larivee
Rejean Larivee
Tivoli Storage Manager Level 2 Support


Leo Humar <lhumar AT BIGPOND.NET DOT AU> on 07/18/2000 11:40:35 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:  restore performance




ADSTAR Distributed Storage Manager Version 3 Release 1 Performance Tuning
Guide
The DIRMc option specifies the management class you want ADSM to use for
directories. The main benefit of managing directories separately from their
files is faster file restore throughput from tape. The directories should
be stored in a DASD storage pool. The DASD storage pool should not require
a lot of space, since directories are typically very small.

In a restore operation, ADSM first restores the directories and then the
files. This order of events can have a negative impact on restore from
tape. For example, if you have slow tape storage pools, i.e., 8mm tape
drives, and the directories are stored on tape with the files, a large
amount of time can be spent searching and mounting tapes to restore the
directories. This time is saved with the DIRMc option by storing the
directories in a DASD storage pool.

Leo Humar
LCS Pty Ltd
lhumar AT bigpond.net DOT au

No trees were killed in the sending of this message. However a large
number of electrons were terribly inconvenienced.