Zoltan,

Shared Dynamic is a very powerful and very dangerous serialization option.
Please make certain that the person who made the decision to use that
understands the implications.

This serialization option will try to back up a file 4 times and then save
the file on the first try during which the file contents didn't change.  The
danger comes with files that continually change and potentially with
applications that require multiple files to be synchronized, like databases.
Net result - you may or may not be able to accurately restore those
applications.

The normal and accepted setting is Shared Static, as you had with the
"problem" client.  So you were fixing the one client that was configured
properly when you should fix all the others.  This will give an error if the
file changes on all four attempts so that a human can decide what to do with
the application backup.

If your university IT personnel understand the implications of Shared
Dynamic and choose to live with the restore consequences, then you can take
the rest of the day off.  Otherwise, you may have a short weekend. ;-)

Bill Smoldt
STORServer, Inc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, February 22, 2002 8:50 AM
To: [EMAIL PROTECTED]
Subject: Re: TSM trying to backup its own, open files..........


Thank you and others for the clue. I had forgot about checking the "backup
copy group" for this node (it has its own while most others share common
ones).

The mode was set to SHRSTATIC vs SHRDYNAMIC (not sure why since everything
else is SHRDYNAMIC ??). I have fixed and activated. This should fix it.

Again, thanks everyone..........
----------------------------------------------------------------------------
------------------------
Zoltan Forray
Virginia Commonwealth University - University Computing Center
e-mail: [EMAIL PROTECTED]  -  voice: 804-828-4807




"Prather, Wanda" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
02/22/2002 10:04 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     [EMAIL PROTECTED]
        cc:
        Subject:        Re: TSM trying to backup its own, open
files..........


I find it useful to have the dsmsched.log file backed up.
That way if I have a user turn up with no backups for something after a
system crash, I can pull down the dsmsched.log from the TSM backups and
see
why (believe me, it has happened before!)

SO instead of excluding the dsmsched.log, I bind it to a management class
that specifies SERIALIZATION=SHRDYNAMIC.   That tells TSM to go ahead and
back it up, whether it's changing or not.

(My management class name for this is "CHANGING", so to bind the file to
that ruleset, you specify:
INCLUDE  *:\...\dsmsched.log  CHANGING
in your dsm.opt file, or the appropriate client option set)

We use the same technique for other sequential log files; then you get a
backup of whatever is in there, up to the last few lines.

Do NOT use this technique for data bases, where change can occur in the
middle of the file.  It also won't work where the error is due to the file
being LOCKED, rather than being open for output.

Just another idea..
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
[EMAIL PROTECTED]

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************





-----Original Message-----
From: Seay, Paul [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 22, 2002 9:32 AM
To: [EMAIL PROTECTED]
Subject: Re: TSM trying to backup its own, open files..........


How does it know it is really its own file?
You have to exclude it if you do not want TSM to try.

-----Original Message-----
From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 22, 2002 9:30 AM
To: [EMAIL PROTECTED]
Subject: TSM trying to backup its own, open files..........


Why is TSM trying to backup its own, open files ?  I thought it was smart
enough to not do this ?

I am getting this error message from an NT 6a node !  The client is
4.2.1.20

 02/21/2002 20:47:46
          ANE4037E (Session: 11678, Node: INFO-OFFICE)  File
            '\\info-office_vcu\c$\Program
            Files\Tivoli\TSM\baclient\dsmsched.log' changed during
processing.
             File skipped.

Also, what is wrong with this exclude statement in my client options file:

Exclude *:\WINNT\Profiles\*

I get these errors:

02/21/2002 20:49:54 Retry # 1  Normal File-->             1,024
\\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG  **
Unsuccessful **

----------------------------------------------------------------------------
------------------------
Zoltan Forray
Virginia Commonwealth University - University Computing Center
e-mail: [EMAIL PROTECTED]  -  voice: 804-828-4807

Reply via email to