I suggest using the ADSM approach.

Allocate, format, define (don't extend) the new db & log files, then do
adsm delete commands on the old db & log volumes.

The volhist and devcon files can be moved & renamed while the server is
down, then change the dsm.opt file.

Alloc, format & define the new storagepool volumes, then do 'move data'
commands on the old ones.

Bill Colwell
The Charles Stark Draper Laboratory
Cambridge Ma.
_________________________Reply Header_________________________
Author: ADSM-L AT vm.marist DOT edu
Subject: Moving DB, Etc. for ADSM/MVS
09-11-96 05:52 PM

When we initially installed ADSM/MVS we placed all of the ADSM server dasd
files (DB, Storage Pools, Volume History, Device Config, etc) under DFSMS
control.  We now want to remove them from SMS control so that if we have to
go offsite to recover only a client paltform, e.g., and not the whole shop,
we can do so with a single pack MVS operating system and not need DFSMS,
et al.  The question is how to make this shift.  Would it be easier/better
to leave the current file names, update the ACS routines to make them non-
managed, and use something like DFDSS to move the files to non-SMS volumes
with ADSM shut down?  Or, allocate new files with non-managed names, vary
the old files offline and let ADSM move the data to the new files? Or...

Has anybody done anything like this or have any suggestions on either what
to do or, more importantly, what not to do?

Thanks,

Frank Rehor
The Clorox Services Company
(510) 847-4814
frank.rehor AT clorox DOT com