Hello David,

        We are using Backtrack as well, have had same problem.  Here's what
     I did to sort-of fix.

     1. Make sure the node is set to BACKDELETE=YES (UPD NODE <nodename>
     BACKDEL=YES).

     2. Setup a new management class as suggested.

     3. ACTIVATE POLicy.  I missed this important piece.  Without it, the
     backtrack data was still going to the old mgmt class.  I got a clue
     here but couldn't understand it.  I kept getting an error messages in
     the DSMI_LOG file, stating that my new management class was not found.
     In reality the new class wasn't found in the ACTIVE policy set.

     4. Issue SHOW VERSION <nodename> <backtrack-filespace>  (note that
     this will take some time, and output should be piped to a file).  This
     will list all files that ADSM knows about for this node, for the named
     filespace, the status, management class used during backups, etc.

     5. Update the original mgmtclass/copygroup info
     (verexists,verdeleted,retextra,retonly) and ACT POL to take effect.
     Wait for file expiration, Then changed back.  This cleaned up quite a
     bit of 'stuff' some of which had nothing to do with Backtrack.

     Backtrack, being an API, creates some, shall we say, uniquely named
     file name entries.  SHOW VER will shed light on this.  Each file
     created via backtrack is unique.  BACKTRACK is the one keeping track
     of the nubmer of versions of database backups, NOT ADSM!  Backtrack
     tells ADSM what to delete, (hence the need for backdelete=yes).

     Here's where the fun begins:  When Backtrack tells ADSM that file xxx
     is deleted, ADSM is supposed to flag the file as inactive and it will
     age off via mgmtclass specs.  Whether or not ADSM does that
     successfully no return code checked, either because the ADSM API
     doesn't return one or BACKTRACK isn't looking, and BACKTRACK deletes
     the file entry from its' control file.  Now you've got a situation
     where Backtrack no longer knows what to tell ADSM to inact, so ADSM
     will hang on to it forever.

     From the ADSM admin side there is NO WAY to tell it to delete/inact a
     file, so like quick sand, once in you sink to the bottom of the pit.
     I've spoken to level 2 about this.  No solutions yet.  We're trying to
     fool Backtrack by manually editing the control file and plugging in
     filename entries as derived from the SHOW VER report.  Not much luck
     yet.

     The only known way to clean it all up is to delete the sql-filespace.

     I believe there needs to be an Admin command which basically says:
     OK ADSM, Forget everything you ever knew about
     '<node><filespace/file>'.

     Good luck,
     Al Barth




______________________________ Reply Separator _________________________________
Subject: SQLBacktrack/Sybase and expiration.
Author:  David Wilshire <DWILSHIR AT LENSCRAFTERS DOT COM> at ~Internet
Date:    6/16/97 10:04 AM


Here's a question for those of you that are using SQL Backtrack's
OBSI module and ADSM for doing backups...

When I originally switched our backups from 4mm tape to ADSM,
we started with level 0 backups daily, unlimited generations, to
our default management class (5 versions exists, 1 version
deleted, 365 days each).  Our thinking was that only 5 versions
would be retained on the ADSM server.

However, we are saw that nothing was being expired out, and our
storage pool occupancy continued to grow.

I called DataTools tech support, who recommended that I set up
a new management class for SQLBacktrack files.  The values
recommended were:  1 versions exists, 0 versions deleted, 0
days each.  Also, the include-exclude file now contains the
stanza, "include /FILESPACE_TAG:*/.../* MGMTCLASS".

I've run backups several times already, thinking that the backup
files would then be bound to the new management class and
that old versions would be deleted, but occupancy continues to
grow.

I have to backup my storage pools for offsite storage, but I've got
about 94GB in old backups I'd rather not save.  It's a waste of
tapes and a waste of time.

Has anyone run into this before?  Is there a safer way to delete
these old backups short of deleting the filespaces and starting
over?

Thank you in advance for your assistance.

David Wilshire, Systems Administrator
LensCrafters, Inc.
dwilshir AT lenscrafters DOT com
(513)583-6801
"Knowledge Is Support"