A couple of weeks ago, I mentioned that we had had a head crash during
New Year's, which destroyed part of our database and asked for help.  Mike
Kacsmarski answered my plea and has been kind enough to help me dig out
of this hole.  I'll post a longer description of all the problems we faced
later, as I don't know how the story is going to end yet.  In a nutshell,
however, the volume destroyed was not a mirror volume as I had thought.
It was a primary database volume that contained real data on it.  I have
rebuilt what I could of the database and am running the AUDITDB to clean
things up.  It started at 7:06 PM on Tuesday 1/10 and is still running.
In two hours, it will hit the 1 week mark and frequently beats out MVS for
CPU time.  He...he...he..he.....  I think this must be some sort of record and
I'll probably be totally "looney-toones" before it finishes.

Here's my dilemma.  Once ADSM is back on its feet, we won't know what data
has been lost due to the incompleteness of the database.  I suspect that
just running new incrementals on each machine won't be adequate.  Files that
have been flagged as having been backed up before the head-crash will not
get backed up again, even though the server copy no longer exists.  Is this
true?  How does ADSM flag a file as being ready for backup?  We are using
OS/2 clients and the VM server.

I would like to be able to re-back up those files that have been lost (or are
new) without forcing a full backup on each machine.  I thought about doing
this by comparing the files on the hard drive with the list ADSM maintains
(QUERY BACKUP) and turning on the attribute for those files that do not
appear on the latter.  Any other ideas?

Martha