ADSM can determine that a file system is not present, but it can not determine
*why* it is not present. While it is possible that the file system has been
deleted, it is also possible that it simply is not mounted, or that it has been
renamed.

For example, on Windows NT, if I have a volume (file system) named APPS and I
rename it to MY_APPS, then ADSM will detect that APPS no longer exists. It will
also detect the presence of a new file system, MY_APPS, but it can not
necessarily conclude that MY_APPS is what used to be APPS. Maybe I meant to
rename the ADSM APPS filespace to MY_APPS, but forgot to do it. In this case,
it would be an unhappy situation if ADSM arbitrarily decided to delete the APPS
filespace from ADSM's inventory. Thus ADSM prefers to err on the side of
caution, and not automatically delete a filespace just because it can't "see"
it.

Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com



ADSM-L AT VM.MARIST DOT EDU on 05/25/98 02:11:19 AM
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: How do you deal with...?


>I'm wondering how large shops deal with the problem that when a filesystem
>is deleted from a client, ADSM will not expire backups of files in that
>filesystem.   I had expected that it should treat them just as deleted
>files,  ...

I would also expect them to be treated as deleted files. What is the philosophy
behind this anomalous behaviour? Is it documented? I don't think large shops
should have to run around in circles looking for this situation.

Could IBM comment on this, please?

Bob Matthews,
University of Geneva.