Re: Strange SA/NV behavior--BK is culprit

[Paul Lagasse pglagasse@xxxxxxxx]

Carl, I agree that your current version of my routine works; I thought
my second comment. further down in the email, where I also asked about
how yr version would interact with a path that included a directory with
an extension, made that clear -- I don't need to try it out to see that
COPY to *.BAK and SA have different triggers.
My remarks about forcing VA$MO to 1, three emails ago, grew out of how
my routine was structured (as I wrote it), and in that context I think
my remarks are correct. Either I didn't make the context explicit
enough, or somewhere along the way the context got lost. I think we've
been talking about two different things.

Paul

Carl Distefano wrote:
Reply to note from Paul Lagasse  Sat, 17 Oct
2009 14:52:06 -0400

Before that copying occurs, FILE.BAK is older (has fewer or
different edits) than FILE. If I use a routine to force VA$MO
to 1 to ensure backups in those few instances (such as a
changed case and the like) where Xy4 has not registered the
change to the open FILE, then FILE will always be backed up
even if I've made no changes to FILE.
 

Not true. The file will not be backed up (copied to .BAK) unless
there are changes to the original file that set VA$MO to 1. And
then, what is being backed up is not those changes, but the previous
disk write of the original file, which is what you want. Try the
routine I posted earlier today. Execute it repeatedly against an
open file without making changes to the file. You'll see that
the .BAK file is NOT updated. What you're missing, I think, is that
immediately after you SAve a file (force an actual disk write),
VA$MO is 0 -- and the backup COPY/NV is only invoked if VA$MO is 1
(i.e., changes were made but *not* written to disk).