Alan Altmark <[EMAIL PROTECTED]> wrote :- >> The FTP client wants filename, filetype, and filemode. You need to unload >> the RACF database to a CMS file and FTP *that* to the MVS site. From >> there it can be FTP'd back to a VM system and then the database reloaded >> from the CMS file.
>> Alternatively, you can use DDR2CMS to create a DDR image of the disk and >> send that instead. Do not copy a minidisk containing a live RACF database >> unless you are using a RACF/VM utility (RACUTxxx) that specifically calls >> out the ability to run it against a live database. Some of the utilities >> do not serialize changes to the database. Thanks for that. To explain a little more of the background. The DR site has just one system up all the time (an MVS system). The current process (on production MVS) takes a IRRUT400 copy of the VM RACF database and then FTP's that to a dataset on the DR MVS system. The DR MVS system then reloads the DR database while VM is down. Due to changes in the volume structure that are necessary in order to run the VM RACUTxxx utilities (they don't tolerate extended/supplementary VTOC's on the output volumes) it is probable that production MVS will no longer be able to read the volumes holding the VM RACF database in order to FTP it. Naturally, any VM procedure would involve taking our own RACUT400 copy as a base for transfer. We had thought about DDR2CMS and that was our last resort because the restore would require more manual intervention. It looks like a MOVEFILE of the RACUT400 copy to a CMS file as the basis for FTP will do the job and leave the restore procedure on the DR site unchanged. Colin Allinson Amadeus Data Processing GmbH
