> Good thought, this could be FRS. It is indeed FRS. FRS is being used as the foundation of a kind of poor mans clustering arrangement. FRS will maintain duplicate copies of application data on pairs of Windows systems. If a production system suffers a catastrophic failure the system's workload will be shifted to the other member of the pair.
The client is Windows 2003, running 5.1.5.0 client software. Our server is currently 5.1.7.2 running under z/OS. The best idea I have come up with so far is to add 'domain -systemobject' to dsm.sys and add a preschedulecmd option to run a .bat file containing a dsmc command. The dsmc command would execute a macro containing commands such as 'backup registry' and 'backup eventlog'. Would this work? In particular, would the domain statement allow the piecemeal backups of system objects to work as expected? Would the TSM server place the files from the piecemeal backups in a 'SYSTEM OBJECT' filespace? Would this approach require changes in bare metal restore procedures? Is there a better way to support operating system recovering without a crippling performance penalty? We are preparing to migrate to a 5.2.2 TSM server under mainframe Linux. As far as I can tell, the operating system backup facilities available when using a 5.2 client with a 5.2 server would eliminate our current problem. Is this a correct assessment?