1) Create the new dataset, copy and load. 2) Uncat the new dataset 3) rename the original dataset on the ALTERNATE RESVOL with volser reference a) expect dsn in use conflict message. Reply to proceed. b) if using ISPF you will see: "Enter new name below: (The data set will not be cataloged.)" 4) rename the new dataset on the ALTERNATE RESVOL with volser reference a) b) if using ISPF you will see: "Enter new name below: (The data set will not be cataloged.)" 5) Recat the original name if needed.
The key to this process is working with the datasets by VOLSER, not CATREF. Most SYSRES datasets are not referenced after IPL. It will make you feel better allocate the datasets on the running system to a job that will execute for the duration expected for this activity (typically < 1 min while DSN's are being renamed), while you manipulate the "new versions". As long as the dataset is intact on the "running" system, existing jobs will be fine. The copy can usually be manipulated at will with appropriate security authorization. I have had this occur many times. Just be very careful to only manipulate the copy, not the original dataset. HTH, <snip> Allan, the problem is that the datasets are on the target res vol with the same name as the dataset on the currently running res vol and they are catalogged in the master cat. Eg. sys1.serblink, isf..sisfload. I can iebcopy them to new bigger datasets with new names on the target res vol but I can't rename them or the current live master cat will be fubarred. </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
