There is a simpler solution to your problem:

In dsm.sys , define

    VIRTUALMountpoint  <directory_specification> [...]

This causes the ADSM client to behave as if the files and directories
stored under <directory_specification> resided on a separate file
system.

In dsm.opt , specify all file systems that SHOULD be backed up in the
DOMAIN option. Omit the <directory_specification> that you want to be
ignored in backups.

This causes the ADSM client to not descend into <directory_specification>.
We use this e.g. for our news spool area and various scratch directories.

Sincerely,  Michael Fink

On Mon, 5 May 1997, Patrick Gilman wrote:

> I agree with Bill, an exclude should be an exclude.  Unfortunately, ADSM 
> doesn't exclude directories it only can exclude files.  Thus while traversing 
> an excluded directory it will backup new directory names.  The only possible 
> suggestion is to try and
place your data that you need backed up on a different partition from the files 
that you want excluded.  I realize this may not be possible but it is something 
to consider.
>
> Patrick Gilman (Vanstar)
> Healthsource, Inc.
> Hooksett, NH
>
> >>> Bill Colwell <bcolwell AT DRAPER DOT COM> 05/01/97 01:49PM >>>
> I think the design is pretty good, as far as it goes, and that it is
> working as designed, so there is no bug to fix.  But clearly there is a
> needed enhancement.  There should be a new statement --
>
>    superexclude <directory_specification>
>
> which tells the tree searching & include/exclude processes to stay out of a
> specified section of the tree, just traverse to the next equal or higher
> level.
>
> IBM, if development of Version 3 is going on now, could this be included,
> if it isn't already covered?
>
> Bill Colwell
> The Charles Stark Draper Laboratory
> Cambridge Ma.
>
> _________________________Reply Header_________________________
> Author: ADSM-L AT vm.marist DOT edu
> Subject: long backup time; not much backed up
> 05-01-1997 12:51 PM
>
> I think we've been here before, but because I still have a problem and
> it has gotten worse of late, I'll try again in hopes someone can
> propose a workaround or IBM will
>
>    * correct the bug
>    * fix the performance problem
>    * correct the BAD design
>    * all of the above
>
> I have an AIX client that has relatively little data to backup, yet its
> backup session takes *many* hours. Today we canceled the backup after
> 10 hours.  The last two hours were viewed by the ADSM (V1, VM) server
> as being wait time.  Yesterday the ADSM server "saw" almost a 5 hour
> "wait time" before the backup completed (in 11 hours).
>
> In every case, the ADSM client is spending all this time spinning his
> way through a couple of million files in subdirectories of directories
> that have everything EXCLUDEd.
>
> That's right, if the ADSM client does not get to a directory and see
> from the include/exclude info that *nothing* could possibly be backed
> up in this or lower directories, but just plods through, file by file,
> looking for something to do.  Meanwhile, a filesystem backup that
> should be done in a few minutes lasts many hours, lasting well into
> times we'ed rather be doing useful work.
>
> Have others seen this problem?  Ditching ADSM backup of (other
> important parts of) this filesystem is not something we'd like to see.
>
> Thanks for listening,
>
> Wayne T. Smith               mailto:wts AT maine.maine DOT edu
> Systems Group -- CAPS        University of Maine System
>

   Dr. Michael Fink +-----------------------------+------------------------
        EDV-Zentrum | Universitaet Innsbruck      | Tel: +43(512)507-2311
 Computing Services | Technikerstrasse 13         | FAX: +43(512)507-2944
--------------------+ A - 6020 Innsbruck, Austria | Michael.Fink AT uibk.ac DOT 
at
=========================================================================