* I apologize if you receive this reply twice - my micro...mail has crashed *

Hi Scottie!

I need same thing as you, and I have not found exactly that kind of 
functionality in ADSM.

It seems the ARCHIVE function was meant to support project backups (or source 
code backups, as you name it).

When ARCHIV-ing, you can  describe the ADSM Archive,
        - write the description down,
        - write used file-space name down,
        - write user name whom does the file space belongs to down,
        - and write the exact date/time down.

Years later you can retrieve exactly this archive using this written 
information.

However, this method has 2 major drawbacks:

 -  First, very serious one is:  you cannot retrieve an archive to another 
destionation if the directory structure is important for you. Yes, retrieving 
an archive to another destination will retrieve all files in the (root of) 
target directory. For me, the ability to restore an Archive to another 
drive/directory is mandatory for project/source code backups.

 - The second drawback is, as you correctly staded, we would need binding of 
archived (group of) data to a name of that Archive, and NOT to the FileSpace 
name.
Binding Backup data to FileSpace name is great for regular backups, but with 
project/software backups we would need Archive Name as "bind name", instead of 
FileSpaceName.
What I mean with that is:
        - making Archive the user would not define its description, but its 
name.
        - the name of Archive coul be used to:
                - get list of Archives (just as we now get List of FileSpaces) -
                  so that Search in ADSM is enough to find the correct Archive, 
without coping with written information.
                - change access rights to the Archive (just as we can do with 
FileSpaces)
                - restore Archives (without knowing what FilaSpace the data was 
proeviously backed-up from)
                - delete Archive (just as we can delete FileSpace)


As far as I know IBM is currently considering improving usability in next 
versions of ADSM, so I am going to make this - or similar - ggestions?  Thanks!
~
~  ------------------------------------------------------------------
~ Purgamentum init,        Scott D. Courtney, Sr. Programmer/Analyst
~ exit purgamentum.        The Timken Company (Canton, Ohio, USA)
~

------ =_NextPart_000_01BBB5D9.D435FFE0--
=======================================================================