Have you tried changing the management class for that file?
For the few cases where you KNOW the file is going to be is use, and you
want a fuzzy backup anyway, you can create a separate management class
(called FUZZY, for example), which specifies SERIALIZATION=DYNAMIC.
Bind that one file to the FUZZY management class in the inclexcl file:
INCLUDE filename FUZZY
SERIALIZATION=DYNAMIC tells TSM to back it up on the first try, whether
it's in use or not.
> -----Original Message-----
> From: Zoltan Forray/AC/VCU [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, October 25, 2000 1:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bytes Transferred Statistics from AIX nodes
>
> Thanks for the info.
>
> Nice thought, but there probably isn't going to be a time when these files
> are "not in use", so fuzzy is better than no backup, in this case!!
>
> IMHO, I think this is a screwball way of doing things. I guess I am too
> accustomed to the MVS way...."check to see if file is in use. No, back it
> up.....next file...if busy and was told to backup files even when
> open/inuse, back it up.........next file....if the file is locked and
> can't
> backup, give up"....not "send 30GB of data down the channel/router/etc and
> then check to see if the file is in use/changed.
>
> In this situation, after further digging, we found that of the 32G sent,
> 24G was duplicate, retries. ADSM wasted numerous hours, tying up
> resources
> and wasting backup time. Even reducing the retry to 1 is wasteful. What if
> one file is 30GB? It is going to waste time, bandwidth, etc. backing it up
> twice..
>
> Again, thanks for the clarification !!
>
>
>
>
> Hi,
>
> It does the sending on each retries. To avoid it, it would have to first
> copy the file in a reserved space, check if the file changed, and send it
> only it has asserted itself it is OK to be sent. This could be a
> worthwhile feature in *SM if it were not for the fact that you'd need to
> have a free space reserve equivalent to the size of any of the file
> bundles
> that are sent at each transmission bursts. *SM were just not designed this
> way.
>
> You may want to exclude the files changing during the backup process, and
> schedule a task to backup those files separately at a time when you know
> they are not going to change.
>
> Serge Gaudet, CMI
> Consultant.
>
>
>
>
> Zoltan
> Forray/AC/VCU To: [EMAIL PROTECTED]
>
>
> Once a week (or so), I go through the ADSM (MVS 3.1.2.50) server activity
> log file, and strip out the "AN?4961I Bytes Transferred" messages to get
> an
> idea of how much data is being transferred/backed up.
>
> Recently, we noticed that a new node (AIX) was transferring more data than
> the total of it's file systems (32GB on a 21GB system).
>
> We turned on VERBOSE logging on the node to see what the !@#$%^&* was
> going
> on.
>
> The only thing we could come up with was the issue of RETRIES on busy
> files. The log would show
> "....transfering....changed....retrying.......transfering.....changed....r
> etrying.....".
>
>
>
>
>
> When we added up the RETRIES bytes plus the total of the filesystem, it
> now
> adds up.
>
> So, why is the "total bytes transfered" including RETRIES ? Does it
> actually send the data, then go back and check to see if the file it just
> transfered changed since it sent the data (kinda doubt it <g>) and keep
> retry/sending until it runs out of retries and then gives up ?
>
> Or is this a client bug ? This is V3.7.2.0 !
