Thomas,

For now, at the 5.1.5 client level, it might be easier to put the
following in your include/exclude list:

   exclude.systemobject frs

This should cause systemobject backups to skip the FRS object, and avoids
the batch file method you mentioned.

You are correct, in 5.2 this will not be an issue.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 09/15/2004
09:03:04:

> > 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?