Stop Version Numbers on a file

[Shelby Donald]

Is there any way to stop the version numbers from incrementing on a file with a version limit of 1

[CharlieCalhoun]

You can't stop it from incrementing, but you can reset the version number on the file that's left. I didn't find this file in the current Freeware CD, but I think that's where it came from many years ago.

After you modify the file, just run the

@SYS$MANAGER:RESET_VERSION_NUMBERS MYFILE.EXT

and it should reset the version number back to 1.

$ dir

Directory

MYFILE.EXT;1

Total of 1 file.
$ ren myfile.ext;1 myfile.ext;2
$ dir

Directory

MYFILE.EXT;2

Total of 1 file.
$ @sys$manager:reset_version_numbers myfile.ext
$ dir

Directory ECP$MANAGER_ROOT:[MANAGER.CALHOUN.TEST]

MYFILE.EXT;1

Total of 1 file.

[Hoff]

There's always the brute-force solution:

file.ext;32767

But rather more seriously, what might you be up to here?

There are ways to deal with version numbers and to roll version numbers back down (contiguously) and to access existing file versions, but an incrementing version number is an inherent and long-standing and default behavior of OpenVMS.

[Robert Gezelter]

Shelby,

Obviously, if one specifies the version number explicitly it does not increment.

Although, in that case, all of the uses of the file must be compatible (e.g., CREATE will be unhappy).

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

The following looks to be a local file:

$ dir sys$manager:reset_version_numbers.com
%DIRECT-W-NOFILES, no files found
$

That (error) is from an OpenVMS Alpha V8.3 box.

The following is the contiguous version RENAME sequence of the following two RENAME commands:

$ RENAME filename.ext;* TEMPORARY.TMP;
$ RENAME TEMPORARY.TMP;* filename.ext;

And that sequence is also in the OpenVMS FAQ, and also discussed elsewhere around the network.

[Shelby Donald]

Thanks for all the help. We are using FTP to send a data file from a linux machine to an OpenVMS machine. I have the Version_Limit set to 1. The task reading the file will delete it, but the problem comes when that task is down for maintenance. Guess I'll have the reading task periodically copy the version to 1. I may try to see if FTP can specify a version number.

[Steven Schweda]

> [...] Guess I'll have the reading task
> periodically copy the version to 1. I may
> try to see if FTP can specify a version
> number.

In general, FTP clients and servers tend to
do what you tell them to do. You may need to
quote a file spec which looks foreign to the
system where you're specifying it. (Like,
for example, something with a semicolon in
it.)

It's not clear to me from your description
what your actual problem is. You seem to
like version 1 better than others, but that
doesn't tell me much.

[Hoff]

I'm inferring here that there are longstanding synchronization issues here with the existing file-passing scheme; that there's rather more here than the version numbering scheme.

So what's wrong with versions other than ;1 here?

Too much disk space for the other files?

Does the OpenVMS tool tip over frequently or with severe consequences? (Or fails to delete lower versions? Or goes down for eons? Or...) Does the tool not delete all earlier versions? (I can see the potential for file lock issues, too, which might well be part of the reason that the OpenVMS process is unstable.)

Or does the OpenVMS server sees the extra bits of the version number as too much extra rotating mass and the disks then implode into a black hole, sucking the rest of the building in after them?

Is ftp appropriate? (Which could include some consideration of other protocols, other file or disk access approaches, and other filenames. Alternatives could include NFS, SMTP mail, IP pipes, http, etc.)

The OpenVMS file version scheme being little more than a primitive version control system, after all.

Would it make more sense to run some secondary DCL that cleans up if the primary DCL is down and the files are older than some interval? An approach which could be considered belt and suspenders, or a longer chain of hackery, depending on how you look at it. Or passing over files with particular names? Or emailing over files?

This discussion can go in many directions. And like a gamma burst from around a singularity, there are some places you don't want to be standing when things go wrong. :-)

[Willem Grooters]

File versioning is required in some environments for legal or maintenance reasons. On VMS it is an integral part of the file specification and can therefore NOT be suppressed. Nor is that needed: ANY decent VMS program will access the highest version of a file if none is specified. FTP included.

You can force a single vesrion if you have all those files in one directory:

$ SET DIRECTORY/VERSION_LIMIT=1

and next forget about version numbers. The only thing you need to do is keep track of the numbers: if you add files, the version number will increase. Once it reaches 32767, adding a new file will fail:

%-E-OPENOUT, error opening as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-W-BADFILEVER, bad file version number

so you'll have to rename that file to version ;1.

and of course, this could be automated using a batchjob.

[Robert Gezelter]

Shelby,

Having implemented more than a few FTP-based file passing applications (in both directions to/from OpenVMS), there should not be a problem if the file version is left to the default, which is the next higher version when creating a file and the highest version when reading a file.

I have also found a few applications that do incorrect things when reading through directories, which does cause a problem if not handled correctly.

There are the usual dangers of prescribing over the phone (sic).

- Bob Gezelter, http://www.rlgsc.com