On 03/25/2014 03:54 PM, Pommier, Rex wrote: > Multiple ways to do this. A couple that come to mind quickly are: > > 1. If the disk volume is completely contained on the single volume (ie the > catalog only has datasets on this volume and all datasets on this volume are > in this catalog) you could EXPORT DISCONNECT this catalog on the current > system, either move the volume to the new system or full volume dump/restore > the volume onto the new system, then IMPORT CONNECT the catalog on the new > system, defining the ALIASes if needed to get to the user catalog. > > 2. Using DFDSS or FDR do a DUMP of the datasets on the current system, > followed by a RESTORE on the new system with CATalog in the restore parms. > You will want to make sure the receiving system either has an appropriate > user catalog set up to get the datasets re-cataloged properly. > > I'm sure there are more ways to do this, but a couple quick hits to get you > thinking. > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Benjamin Huntsman > Sent: Tuesday, March 25, 2014 3:39 PM > To: [email protected] > Subject: Moved DASD - import catalog > > This is a theoretical exercise, and I'm a newbie, so please pardon me if this > is basic stuff... > > Let's say I have a DASD volume on one system, and it has a user catalog on it > for all the datasets on the volume, and I want to move this volume to a > different system that knows nothing about it currently. > > How would I go about first, verifying in the user catalog that there aren't > going to be any name conflicts with datasets on other volumes, and two, > importing the catalog into the receiving system's master? I suppose I could > just recatalog everything, but that might be painful, especially for any VSAM > datasets... > > Or would it just be simpler to backup all the datasets on the source system, > then restore them onto the target system on a new volume? > > Many thanks! > > -Ben > > And hopefully things have been done right so that all the data sets cataloged in the user catalog are accessible via normal search order (required if the volume is SMS), which means there are one or more aliases which point to the user catalog that is to be moved that cover all data sets in the user catalog and on the volume. As long as the high-level qualifier(s) associated with those aliases don't conflict with any data set names or existing aliases on the target system you are OK. Otherwise, even if you can connect the user catalog to the new system you won't be able to define all the required aliases on the target system and some data sets may be inaccessible. If there are name conflicts, you will first have to rename data sets either on the volume to be moved or on the target system to eliminate the conflicts before attempting the process.
If you know in advance you want to do this with a volume with self-contained USERCAT, the simplest approach would be to assign a unique (on both systems) HLQ (or unique prefix if multi-level aliases are being used) for all data sets on the volume so they may be associated via alias with the volume's user catalog, no matter with which system it is connected. Don't forget to set up appropriate security profiles on the target system for the data sets on the volume being moved, since if their HLQs are unique they probably are not covered by any pre-existing profiles. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
