As a bare bones approach, your scenario should work...in a perfect world. Personally, I'd suggest you consider the following:
1.) Run DIAGNOSE ICFCATALOG for the source catalog (at the very least) prior to attempting the REPRO. "Dirty" entries may halt the REPRO and multiple "dirty" entries may halt the REPRO multiple times...it's a serial process. This may also identify any offline volumes that might be affected. Keep in mind that RERPO MERGECAT will update the VVRs and NVRs as part of the REPRO process. 2.) If moving a lot of entries, I'd suggest you remove the catalogs from cache. REPRO updates both the source BCS (deletes entries after copying) and the target BCS (write new entries). Catalog Address Space caching (either CDSC or ISC) buffers for "look-up". A high volume of update activity causes the cache to be loaded and invalidated for each update. A higher level of performance will be achieved if the catalogs are not cached. F CATALOG,NOISC(catalog.name) - or - F CATALOG,NOVLF(catalog.name) 2.) I like to recatalog my aliases after I know that I've moved entries, but I think you can make a case for either sequence of events. My fear is that someone will catalog an entry into the target that will create a duplicate entry situation during the REPRO. Of course, it's as likely that someone will define an entry to the source catalog after the REPRO is completed and will be unable to locate that entry after the aliases have been recataloged, but that won't adversely affect the REPRO. You certainly do NOT want to delete the alias, REPRO the entries, and re-define the aliases as this sequence may cause entries to get cataloged in the master catalog. 3.) Even though REPRO performs a lot of "synchronization" logic, I would still recommend that the effort be undertaken during off-peak hours. It just seems to make sense to minimize the potential for errors and the impact that they may cause. 4.) It's never a bad idea to create backups of both the source and target catalogs. If the number of affected DASD volumes is a manageable number, I'd backup those as well. 5.) Datasets that are OPEN elsewhere can not be moved. There are products on the market, T-REX is one, that performs the required process exponentially quicker and can help you on the above points. It can be run in a simulate mode that not only gives you a list of selected datasets that would be moved, it will also perform the ENQs for you to determine if a file is OPEN elsewhere. If a file is OPEN, the owning resource is indicated. Give me a call offline if you want to talk some more. I'd be glad to share our experiences. Larry Crilley Dino Software, Corp. http://www.dino-software.com/ 412-734-2853. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
