Text item: Body.822
I would add step 2a).  'move data <volumes_in_diskpool> stg=<tapepool> to
force any lingering cache copies to be removed from the database.  If your
%mig and %used aren't equal in 'q stg' when you do the migration, you must
do this.

I think you can change the names of the flatfiles and the db and log
volumes.  I did a test restore of the prod database while the prod adsm was
up and running on the same system.  I had to used different vsam files.
The restore ran ok, but I didn't do the final step of the test which was to
start adsm with the restored database since that would have allocated the
production disk stgpool.

Good luck!

Bill Colwell
The Charles Stark Draper Laboratory
Cambridge Ma.
_________________________Reply Header_________________________
Author: ADSM-L AT vm.marist DOT edu
Subject: Moving my Server....
09-09-96 02:50 PM

Date:         Mon, 9 Sep 1996 14:50:41 -0400
From:         Jerry Lawson <jlawson AT itthartford DOT com>
Subject:      Moving my Server....
To:           Multiple recipients of list ADSM-L <ADSM-L AT vm.marist DOT edu>

Date:     September 9, 1996            Time:    13:48
From:    Jerry Lawson
    ITT Hartford Insurance Group
    (860) 547-2960    jlawson AT itthartford DOT com
---------------------------------------------------------------------------
--
--
We will have to move our V2 MVS server from one MVS system to another.
We will have to move our V2 MVS server from one MVS system to another.
Both
images reside in the same room, but currently no physical devices are
shared
between the two images.

In going over the move in my mind, I came up with the following plan, which
borrows heavily from the disaster recovery plan.  On the old image:

1.  Disable new sessions; insure all old sessions are completed.

2.  Migrate all DASD pools to tape by setting the values to HI=1, LO=0.
Turn
off caching before this occurs.

3.  When migrations are complete, force a Data Base backup.

4.  Halt the server, then backup all flat files, such as Vol-history,
device
config, Server options and TSO admin options.

In the new complex:

5.  Restore the flat files from step 4.

6.  Allocate new data base and storage pool volumes, and format them.

7.  Restore the Data Base using tape from Step 3.

8.  Bring up server, but keep sessions disabled.

9.  Mark old tape pool as read only; allocate new tapepool for new machine.

10.  enable sessions and we should be in business.

NOTE:  Step 9 is not a necessity, but our operations staff wants to see it,
since the two machines have separate tape catalogs, and we segregate our
tapes
by TSN.  That is - the old image has TSNs that begin with 8xxxxx, while the
new image has tapes that begin with 1xxxxx.  By marking the old pool as
read
only, I keep old tapes from being written to.  The number of tapes in the
old
pool will drop as tapes are reclaimed and returned to scratch, and new data
will only be written to the new pool.  When the number of tapes gets down
to a
manageable number, I will then do MOVE DATA commands to move the remaining
volumes to the new pool.

Questions:

1.  Anyone see any holes in this scenario, or have suggestions for
improvement?

2.  How much latitude do I have to change names of data sets in the pool
and/or the Data Base?

It would seem to me that I can change the names and volumes of the pool
data
sets, but I am not so clear about the Database, since I will be restoring
the
old DB as if it were a system failure.

Jerry Lawson
jlawson AT itthartford DOT com
***************************************************************************
**