In <0017000005925044000002L042*@MHS>, on 03/13/98
   at 12:41 PM, "Moir,Betsy" <Betsy.Moir AT LN.SSW.ABBOTT DOT COM> said:

>As I was reading up on dumpdb, loaddb and auditdb I got the impression that
>I had to have a db to dump in the first place before anything else could be
>done.  It was my understanding that this was used for corrupted databases.

>I know I've been very close mouthed about what happened here - probably
>reducing our chances for help - but I'm attempting to save faces.  We were
>allocating new db dasd.  The volume numbers currently being used were
>400,401 and 402.  The new volumes were 500,501,502.  When it came time to
>format the "new" volumes the numbers entered to be formatted were
>400,401,402.  Bye-bye database.  The reason we can't do db restore is
>because the full backup tape has been written over.  If I go any further
>into the tale of why we don't have db backups I'll start getting nasty and
>I don't want to do that.  We do have full backups using vmbackup and we're
>trying to get some help from IBM on whether or not a restore from here
>possible.

>Any creative and/or completely off-the-wall ideas from anybody are welcome.

At this point I would restore the vmbackup's for the db, log and the other
small files.  I assume that you haven't done this yet becasue you took the
backups while the server was running, and therefore the server won't start.
But now you will have some input for dumpdb to work on. Get this done soon
so that you can at least see if dumpdb will work. You will need the weekend
for loaddb & auditdb.

You can do the load onto the 5xx volumes, after doing a /install on them and
the associated recovery log.
--
-----------------------------------------------------------
-----------------------------------------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma
bcolwell AT draper DOT com
-----------------------------------------------------------
=========================================================================