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....retrying.....".
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 !
