Or..

     1. Use dsmfmt to allocate/format new db areas.
     2. DEFINE DBVOLUME(s) (new names from above) to adsm.
     3. DELETE DBVOL (old name)    --  this will make adsm migrate db info
     from the old.name area to new.name area(s)
     4. cd  to wherever old files are
     5. rm  old.named.file

     I've used this many times while the server is running.  It's still a
     good idea to have a backup tho'.

     Al Barth
     Zurich Kemper Investments



______________________________ Reply Separator _________________________________
Subject: Re: Moving the ADSM database
Author:  David Ong <david AT BABYONG.NSC DOT COM> at ~Internet
Date:    8/11/97 11:20 AM


Jeff,
If you can define the new set of disks within the same volume group, you
can use the smit & move physical volume to migrate the databases. The nice
thing about this is that you can leave the ADSM server up while the migrate
is being done by AIX.
If the new disks are in a different volume group, then you would have to:

 - shutdown ADSM server
 - umount your dbs
 - rename filesystem names of the dbs (eg, /adsmdb1 to /adsmdb1.o) and
re-mount them
 - create filesystems for the dbs on the new disks using original FS names
(eg, /adsmdb1) and mount them
 - copy the db files ( *.dsm) from the old disks to the new disks
 - restart the ADSM server

The reason for going thru the filesystem renaming routine is because the
server keeps track of the physical path names for all the dbvolumes and
logvolumes so that you cannot simply 'fool' it by changing the entries in
dsmserv.dsk.

The db backup & restore method would be the least preferred option for me.
Besides, you would still have to go thru the filesystem renaming routine.

At 11:24 AM 8/11/97 +0000, Jeff Hoover wrote:
>I have a simple question I believe.
>
>We are running AIX 4.2.1 and ADSM 2.1.5.13 server. We need to move our
current
>ADSM database off its current set of disk and onto another set of disk. I
>notice that the database is comprised of files .dsm.
>
>Can I just copy those files over to the new disk either with smit and move
>physical volumes, or with the unix cp or mv commands?
>
>Or do I have to actually do a backup, remove the physical disk, put in the
new
>disk, re-build the database files and restore?
>
>
>Thanks
>
>
>
>
>Jeff Hoover
>Systems Programmer
>New Mexico State University
>
>jhoover AT nmsu DOT edu
>
>

Have a nice day or whatever's left of it.

David Ong
National Semiconductor Corp.