ADSM-L

Re: Huge system object

2004-09-15 13:03:42
Subject: Re: Huge system object
From: fred johanson <fred AT MIDWAY.UCHICAGO DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 15 Sep 2004 12:04:16 -0500
I've seen no problems at 5.2.2.5.  A few years ago when I first saw this
phenomenon, the machine was sending more than 500 Gb a session.  the
machine admin figured out the problem and devised his own solution.


At 12:49 PM 9/15/2004 -0400, you wrote:
I dunno if that will eliminate all your problems.
But I thought there were known issues with the TSM client not handling the
Win2K3 System Object correctly until you get to 5.2.3.



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Thomas Denier
Sent: Wednesday, September 15, 2004 12:03 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Huge system object


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

Fred Johanson
ITSM Administrator
University of Chicago
773-702-8464

<Prev in Thread] Current Thread [Next in Thread>