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

[Shelby Donald]

Thanks,
I have the Version_Limit=1.
Guess I'll have a batch job, as you have suggested, to go rename the file.

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

The problem occurs because the jobs run continuously and a new file is sent every 15 seconds. There is normally no user intervention. It gets to 32767 and the data appears to stop updating. I had not thought of a batch job to check the version number and reset it when necessary, or just reset it at midnight each day.

[Robert Gezelter]

Shelby,

Okay, the last post clarified some issues. It is not the version number that is actually the problem, it is the maxing out of the version numbers when a new file is created every 15 seconds (15 second interval == 4 files/minute, 240 files/hour, 5,760 files/day, ... -- in essence, the file version hits the ceiling in a little less than one week).

Care need be exercised when resetting the version numbers when files are being actively created. It is easy to have a collision and switch the latest and next to latest files.

If the process generating the files is running free, I would recommend caution, and a threshold some point before the 32K limit.

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

[Jess Goodman]

Since you have only one version of the file all you have to do (in a daily batch job for example):

$ RENAME filename.exe ;1

Note that this will reset the version limit of the file to the directory's default version limit. So if that is not also 1 you must reset the file version limit back to 1 after the above.

When multiple versions of a file have to be RENAMEd to lower the high version numbers I use a command file which has a loop of F$SEARCH and RENAMEes. I can post this if asked.

The suggested temporary file RENAMEs method is ok if used interactively (when you can check it with DIRECTORY commands), but it NOT safe to use in a daily batch job or another automated fix.

Consider what would happend if a new filename.ext was created while either of these two RENAMEs are executing, or in between them.

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

The newest file would not end up with the highest version number!

[Hoff]

The whole scheme here seems somewhat unstable at best, resource intensive, and rather prone to various failures including lock collisions and failed processes, and also exposed to lost or duplicate data.

This is not the solution I'd usually pick, not a 15 second file-polling ftp-based file transfer. From experience architecting these and resolving these over the years, this case looks to be an old and seemingly stable and simple solution that was speeded up to meet newer responsiveness requirements. And a solution that has become somewhat unstable, and somewhat problematic as the transfer latency has been lowered and/or as the bandwidth has increased.

But if the customer here is operating with knowledge of the limits of the current data transfer design, well, okfine...

[Shelby Donald]

The choice of data transfer methods was not up to us. We are interfacing with a vendor supplied piece of software.

[Willem Grooters]

SENDING files only? Let me suggest another approach.
Does it HAVE to be on port 21 (default) of could you use another port to do this?
If so, this is what you could do:

* Copy the command procedure that is usually on port 21 (TCPIP$system:TCPIP$FTP_RUN) to another location and name.
* When done, do a PURGE of all files and rename the remaining failes to version 1.
* Create a new service on any port you like - similar to the FTP service, name this procedure /FILE, and give the process a distinctive name; limit sessions to 1 (to prevent clashes): /LIMIT=1

Now use this service to upload your files.

If you need more concurrent sessions, be sure to serialize and prevent time-out....

[Willem Grooters]

To clearify:

> When done, do a PURGE of all files and rename the remaining failes to version 1.>

meant to be the adjustment in the copy of TCPIP$FTP_RUN.COM:

...
$ RUN SYS$SYSTEM:TCPIP$FTP_SERVER.EXE
$!
$!---Adjust below vvvv
$ PURGE/LOG
$ RENAME *.*;0 ;1 ! or similar, in code
$!---Adjust above ^^^^
$ EXIT

(You can actually do ANY command, even SET DEFAULT, allow specific users only, take other activity based on whatever user of system is accessing the service..)

[Thomas Ritter]

Shelly, we run two large scale commercial ftp drop boxes moving hundreds of files amounting to gigabytes of data every day, one linux based, the other VMS based. Down here, all files which move between these drop boxes have a timestamp embedded somewhere in the file name. This way we only ever have 1 version of any file. Consider the use of timestamps in file names.