"Dave Gullen" wrote in message
news:fde9c9a2-9f55-4143-9ff3-ce29e12b9f31@e39g2000hsf.googlegroups.com...
> Hi,
>
> I've recently discovered that a semicolon in the output file spec of a
> backup command results in file versions restored in reverse date
> order. I found this when trying to work out why a colleague's restore
> command was doing this - it was just a typo, so a completely
> serendipitous discovery.
>
> I've been trying to work out the 'VMS Logic' of this. Any
> suggestions? Anyone seen this before?
>
> Cheers,
>
> Dave G
>
> $ dir/date TEST_FILE.TXT;*
>
> Directory GSE_USERS:[GULLEN_D]
>
> TEST_FILE.TXT;1846 11-MAR-2008 06:00:03.52
> TEST_FILE.TXT;1845 10-MAR-2008 06:00:03.41
> TEST_FILE.TXT;1844 9-MAR-2008 06:00:03.01
> TEST_FILE.TXT;1843 8-MAR-2008 06:00:03.10
> TEST_FILE.TXT;1842 7-MAR-2008 06:00:03.23
> TEST_FILE.TXT;1841 6-MAR-2008 06:00:03.05
> TEST_FILE.TXT;1840 5-MAR-2008 06:00:03.10
> TEST_FILE.TXT;1839 4-MAR-2008 06:00:03.30
>
> Total of 8 files.
> $
> $ backup TEST_FILE.TXT;* test.bck/save
> $ del test_file.txt;*
> $ backup test.bck/save []; !<- Note the
> semicolon
> $ dir/date TEST_FILE.TXT;*
>
> Directory GSE_USERS:[GULLEN_D]
>
> TEST_FILE.TXT;8 4-MAR-2008 06:00:03.30
> TEST_FILE.TXT;7 5-MAR-2008 06:00:03.10
> TEST_FILE.TXT;6 6-MAR-2008 06:00:03.05
> TEST_FILE.TXT;5 7-MAR-2008 06:00:03.23
> TEST_FILE.TXT;4 8-MAR-2008 06:00:03.10
> TEST_FILE.TXT;3 9-MAR-2008 06:00:03.01
> TEST_FILE.TXT;2 10-MAR-2008 06:00:03.41
> TEST_FILE.TXT;1 11-MAR-2008 06:00:03.52
>
> Total of 8 files.

Presumably it is backing up ;8 to []; and calling it ;1, then backing up ;7
to []; and calling it ;2, and so on?
--
David Biddulph

In article , Dave Gullen writes:
> Hi,
>
> I've recently discovered that a semicolon in the output file spec of a
> backup command results in file versions restored in reverse date
> order. I found this when trying to work out why a colleague's restore
> command was doing this - it was just a typo, so a completely
> serendipitous discovery.
>
> I've been trying to work out the 'VMS Logic' of this. Any
> suggestions? Anyone seen this before?
[snip]
> $ backup TEST_FILE.TXT;* test.bck/save
> $ del test_file.txt;*
> $ backup test.bck/save []; !<- Note the

Yes. That's expected behavior.

A semicolon with no version number is treated as ";0". Version 0 is
treated as "highest existing version" on input and as "next higher
version" on output. If there is no pre-existing file, version 1 is
used on output.

Wildcards are normally scanned in reverse version number order.

So the BACKUP save pass processes TEST_FILE.TXT in reverse version
number order, saving versions 8, 7, 6, 5, 4, 3, 2 and finally 1.

The BACKUP restore pass processes the save set in sequential order.
It finds TEST_FILE.TXT;8 in the save set and restores it as
TEST_FILE.TXT;0. That results in the creation of TEST_FILE.TXT;1

It finds TEST_FILE.TXT;7 in the save set and restores it as
TEST_FILE.TXT;0. That results in the creation of TEST_FILE.TXT;2

The result is the the version numbers are reversed.


This same trick is sometimes used to re-version files in a directory
so that version numbers start at one (rather than incrementing on
toward the version limit of 32767).

$ PURGE /KEEP=100 BATCH_JOB.LOG
$ RENAME BATCH_JOB.LOG;* [TEMP_DIR]*.*; ! Reverses version numbers
$ RENAME [TEMP_DIR]BATCH_JOB.LOG;* []; ! Reverses them back

In article , Dave Gullen writes:
> Hi,
>
> I've recently discovered that a semicolon in the output file spec of a
> backup command results in file versions restored in reverse date
> order. I found this when trying to work out why a colleague's restore
> command was doing this - it was just a typo, so a completely
> serendipitous discovery.
>
> I've been trying to work out the 'VMS Logic' of this. Any
> suggestions? Anyone seen this before?

The wild card ";" for a version, means "highest". If you're opening
an existing file, its the highest one. If your opening a new file
it's one more than the highest one. BACKUP, like most utilities,
processes files highest version first. It obeys what you tell it
to do in creating output files.

Dave Gullen wrote:
> Hi,
>
> I've recently discovered that a semicolon in the output file spec of a
> backup command results in file versions restored in reverse date
> order. I found this when trying to work out why a colleague's restore
> command was doing this - it was just a typo, so a completely
> serendipitous discovery.

someone has been doing too much UNIX perl or shell scripting

In article
,
Dave Gullen writes:

> Hi,
>
> I've recently discovered that a semicolon in the output file spec of a
> backup command results in file versions restored in reverse date
> order. I found this when trying to work out why a colleague's restore
> command was doing this - it was just a typo, so a completely
> serendipitous discovery.
>
> I've been trying to work out the 'VMS Logic' of this. Any
> suggestions? Anyone seen this before?

How does it work without the semicolon? It does it correctly, i.e. the
newest file dates have the highest version numbers. If you specify a
semicolon, you override the default version number. Presumably, it
restores them starting with the highest version number, and the
semicolon gives this ;1 when no files are there. The next highest
version number gets ;2 etc.

When restoring from a backup saveset, I normally just give a directory
(and perhaps disk) as the output file spec. Occasionally, I might want
to give a file name, but why just a version number (or *, since it has
the same effect as no file spec in this case)? Note that you cannot
restore just the highest version file from a saveset:

BACKUP_Command

/SELECT

/SELECT
/SELECT=(file-spec[,...])

Input Save-Set Qualifier

Selects the specified files for processing. If you specify more
than one file, separate the file specifications with commas and
enclose the list in parentheses.

Do not use a device specification when you define the files to be
selected. You can use most standard wildcard characters, but you
cannot use wildcard characters denoting latest version of files
( and relative versions of files (;-n).

In article , helbig@astro.multiCLOTHESvax.de
(Phillip Helbig---remove CLOTHES to reply) writes:

> How does it work without the semicolon? It does it correctly, i.e. the
> newest file dates have the highest version numbers. If you specify a
> semicolon, you override the default version number. Presumably, it
> restores them starting with the highest version number, and the
> semicolon gives this ;1 when no files are there. The next highest
> version number gets ;2 etc.

BACK/LOG will show that files are created and restored in reverse order
if no file spec forcing another behaviour (like is specified.

In article
,
Dave Gullen wrote:

> I've recently discovered that a semicolon in the output file spec of a
> backup command results in file versions restored in reverse date
> order. I found this when trying to work out why a colleague's restore
> command was doing this - it was just a typo, so a completely
> serendipitous discovery.
>
> I've been trying to work out the 'VMS Logic' of this. Any
> suggestions? Anyone seen this before?

It's not reverse date order, but reverse version number order.

A semicolon means "highest version number", as does ;0.

Let's look at the order that BACKUP processes files:

$ backup/log test.txt test.bck/save
%BACKUP-S-COPIED, copied SYS$SPECIFIC:[SYSMGR]test.txt;2
%BACKUP-S-COPIED, copied SYS$SPECIFIC:[SYSMGR]test.txt;1

I.e. BACKUP backs files up in reverse version number order.

When you restore the save set using a semicolon in the output
specification, each file restored goes to the highest version number,
hence the reversal.

Another tip: version ;-0 means lowest version number:

$ dir/col=1 test.txt

test.txt;7
test.txt;6
test.txt;5
test.txt;4
test.txt;3

Total of 5 files.

$ dir test.txt;-0

test.txt;3

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html