>   As you will soon see, I am not too familiar with the operation of
>the ADSM VM server.  In an attempt to move to new DASD, I mistakenly
>used the DSMINST EXEC (instead of DSMMDISK) to add new minidisks.  I
>see now that this was a HUGE mistake.  The only backup that I have of
>the recovery log and database volumes is a DDR backup from the previous
>week.  I restored my recovery log and database minidisks (200/300 &
>201/301) from the DDR tape, and now receive the following at startup:
>
>ANR0900I Processing options file DSMSERV.OPT.
>ANR0990I ADSM server restart-recovery in progress.
>ANR0215W Recovery log volume 0200 is in the off-line state - VARY ON required.
>ANR0200I Recovery log assigned capacity is 28 megabytes.
>ANR0201I Database assigned capacity is 116 megabytes.
>ANR0306I Recovery log volume mount in progress.
>ANR0353I Recovery log analysis pass in progress.
>ANR0354I Recovery log redo pass in progress.
>
>DM0001S Run-time assertion failed: "recLen + sizeof( tbKeyDir ) <= 
>nodeP->info.f
>
>
>DSM server terminating operation - internal error TBINS069 detected.
>
>   At this point, I don't much care if I lose the data in the storage pool,
>but I would really like to avoid having to recreate all of the system setup
>info from the previously existing system (schedules, tape storage pool #'s,
>authorizations, etc.)
>   Does anyone know a graceful way out of the mess that I have gotten myself
>into?  Any help will be tremendously appreciated.
>
>David R.

Don't know if you got an answer already or if this is still pertinent, I was
out of town for a few days, but I have experienced similar errors and I can
tell you the way I have backed myself out.  If it's graceful or not is another
question.

The "dsmserv dumpdb" command is the trick. It allows you to dump all the
databases (including all your schedules, nodenames, policy domains, storage
pool definitions w/o really launching the server. You must make a couple
of definitions in the dsmserv.opt file to run the commands. Read the fine
manauls for this.

After dumping the databases you must reinstall via:

dsmserv install (with fresly formatted db and log files)
dsmserv loaddb (the one you dumped)
dsmserv auditdb  (this one will figure out what is really there and what is
                   not)  BTW count on some time. For my 2.5 million files it 
took
                         4-6  hours.

dsmserv can now be launced normally and the files lost in the process will
be backed up on the next incremental.  My personal feeling is that dsm is
mighty squemish when it doesn't find exactly what it expects in the db, log
or diskstorage pools, but at the same time I feel pretty confident that when
it thinks it has a copy of your file it does.