If you stop ADSM then run a full volume dump of all ADSM files (i.e DB + all
storage pools + recovery logs), YOU SHOULD BE ABLE TO RESTORE AT DISASTER SITE,
The ADSM system will come back up, just like it looked before  you stop it. We
use FDR/ABR to do FULL VOLUME dumps, because it the fastest and most reliable.
The DB and Storage pools have to be in sinc.

______________________________ Reply Separator _________________________________
Subject: Disaster recovery results....
Author:  ADSM-L AT VM.MARIST DOT EDU%smtp at x400po
Date:    4/21/97 12:08 PM


     Well, I feel all "special" today... and why does "Mac Truck" come to
     mind when I say that?

     In general, things went OK.  It was an educational experience.  Where
     some things didn't go as planed, I had already expected most of those.
     Example, we're shooting for having real time mirrored volumes of the
     production environment at our disaster environment, system stuff that
     is and adsm's dbvols are included in that list.  Currently that isn't
     the case but we have the dasd there and do daily full volume dumps and
     restore them to spinning dasd at the disaster site.  This really does
     us no good currently with ADSM 'cause we don't pause ADSM while all
     these dumps are taking place.  I didn't let that stop me from at least
     trying to bring ADSM up against those DB & LOG datasets.
     Yes,  you guessed it right... didn't work.
     ANR0259E Unable to read complete restart/checkpoint information from
     any database or recovery log volume.
     OK, scratch all DB & LOG files and go from there...
     I deleted and reallocated the files with the IEFBR14 & ANRFMT2 pgms as
     listed and thought (silly me) that that would allow the restore db to
     run. NO! I had to also run the dsmserv install against the files.  OH
     and silly silly me, I tried to do a single run against 3 logs and 4
     DB's (I really have 8 db's with the mirrors but I was only worried
     about 4)  How much time did I waste trying to figure out how to code
     the continued JCL statements with PARM='/INSTALL 3 HLQ.ADSM.RECOVER1
     HLQ.ADSM.RECOVER2 HLQ.ADSM.RECOVER3 4 HLQ.ADSM.DB1 HLQ.ADSM.DB2
     HLQ.ADSM.DB3 HLQ.ADSM.DB4'  enough time to get it right, then I got
     the message that the parm was coded correctly BUT JUST TO DANG LONG!
     So I got out my inflatable hammer and beat on the terminal for a
     while. ;-)  then cut things back to a single log & a single DB (the
     'ol kiss method... Keep It Simple, Stupid!), ADSM would now start.  I
     then used the console to register myself as an admin and granted
     myself system authority, THEN had to enter adsm and define all the
     other DB & log vols.
     Now I was ready to restore the db and started to until RMM wouldn't
     let me mount scratch tapes for input (ARGH!). Obviously I had more
     ADSM seq vol hist than RMM had information so rather than waste time
     getting someone to update RMM I just backed up one DBBackup tape set.
     AAAHHhhhhhhh! All restored... I was feeling all better until I went to
     start ADSM (so I could update the diskpool vols to access=destroyed)
     and it wouldn't restart 'cause as it tried, it realized the diskvols
     were gone and hit some magic number/limit that it wouldn't go beyond.
     So it was back to batch dsmserv jobs to perform these tasks...
     At this point I decided there is always another day.  Heck, I'm not
     even really MVS ADSM, I'm the AIX kind'a guy now and have been for a
     couple of years!  I knew I shouldn't have asked who was going to test
     the recovery of ADSM in that meeting!

     I didn't hit any BIG problems... I was happy with the point I reached
     and the information I gained.  Unfortunately it did pile more work on
     me but... job security!

     later
          Dwight

------ =_0_MIME_Boundary_4250.335bb9fa.dcuh029.dcu.ps.net--
=========================================================================