the copy.com don't run the next command

[SCC_2]

Hello Doug,
I can't use /new on my backup command. Because that directory have a lots of data inside, I will run out of disk spaces before the backup is complete.
I will do more testing to see what fit me the most. The worst case is I delete all files in dka100: first then copy all dka200: over.
SCC

[Doug Phillips]

>>
Because that directory have a lots of data inside, I will run out of disk spaces before the backup is complete.
<<

Ahh, the PURGE made me think that you expected two versions to end up on DKA100.

>>
The worst case is I delete all files in dka100: first then copy all dka200: over.
<<

As long as you're getting them backed up to tape or someplace else first, that might be the best way. Otherwise, if the files in both directories can be absolutely kept at the same version numbers, the /replace should work. If the files on dka200 are sure to not be in-use when you do the copy, you could do a rename to ;1 beforehand.

Without knowing the nature of the files, it's hard to say what's best.

[SCC_2]

Hello Doug,
Yes, your idea will work fine for this. Coping all data from other disks to dka100: is just an extra protection to us. Just in case if I have to pull out data from yesterday I can get it from dka100:
I do have another image backup backing up all drives at night on tape.
Thanks !
SCC

[Antoniov.]

Hi,
I'm dubt about using of /NEW qualifier. Even if after of backup you execute PURGE command, you must have enough space on disk to keep two backup.
There no advantages of using /NEW; just /REPLACE makes a copy and keep same version of file. If you have text or log files it's simpler hold same version.

Antonio Vigliotti

[Jan van den Ende]

SCC,
DOUG,

I am with Antonio on this one!

If _ALL_ these conditions are true:

- a file with EXACTLY the same name AND version exists in both directories
- you have DELETE access to the files in the target directory
- the files in the input directory AND in the target directory are NOT currently locked
- each file in the input directory and the corresponding file in the target directory have THE SAME attributes
- the BACKUP command has the /REPLACEqualifier specified

then

upon execution,

the DATA in the target file(s) will be REPLACED by the data in the source file(s).

So, if you can make sure of the SAME version numbers for the corresponding files, there is NO need for extra diskspace.

On the other hand, if you specify /NEW, then,
if any version of the target file exists, and the version of the source file is not greater, the version of the new output file will be one grater than the existing one.

Some(simplified) examples of /NEW

SOURCE:AB.CD;5
SOURCE:EF.GH;2
SOURCE:IJ.KL;7
SOURCE:MN.OP;17

TARGET:AB.CD;5
TARGET:EF.GH;8
TARGET:IJ.KL;3

Result of BACKUP/NEW:
TARGET:AB.CD;5
TARGET:AB.CD;6
TARGET:EF.GH;8
TARGET:EF.GH;9
TARGET:IJ.KL;3
TARGET:IJ.KL;7
TARGET:MN.OP;17

Result of BACKUP/REPLACE:
TARGET:AB.CD;5
TARGET:EF.GH;2
TARGET:EF.GH;8
TARGET:IJ.KL;3
TARGET:IJ.KL;7
TARGET:MN.OP;17

Mind the differences for AB.CD and EF.GH


hth

Proost.

Have one on me.

jpe

[SCC_2]

As a matter of fact, this is very easy for me to find out how the data was create new or update from other file.

Everyday we download a lot of data information from the PC to the Vax, they all
end at *.txt, or *.;*, and I can copy this over anytimes I want no problem.

When we create a quotation to a customer the program will create a new quotation number
start at q******.###, (****** is the quote number, and ### is the date count since 01-jan, example today is .223 which mean 223 date since 01 jan 05).
The rest of the files end at *.trs, which this type of files will got updated but the version number will not change, unless I init the files. So what I am trying to do right now is to copy all files since = today, exclude *.trs, and then another command /replace all *.trs will solve my problem. Since the *.trs file is the major one and this files is big.

SCC

[Doug Phillips]

SCC,
Reading your explanation of how the files are created, I think you are on the right track. I'll bet you probably have your directories set to version limit = 1, too, which will make things cleaner.

Antonio & Jan,
You are right about /new vs. /replace, and Jan, your comment about version numbers is *most* important (I think I mentioned it in my post, too).

One *major* caveat with backup/replace and backup (no switch) is if the source file has a lower version than the target. Your EF.GH example shows this clearly. Your conditions and examples are (as usual) right on.

I'll mention, too, that using /new when a source file has multiple versions will invert the version so that the oldest file has the highest version number. This is also not usually a good thing;-)

Given sufficient disk space, though, I do prefer to do a /new followed by a purge when running tasks like this unattended. Don't know, maybe just paranoia or maybe too many times being burned by something unexpected. My comfort level makes it hard for me to use /overlay, too:^(