The Question is:
We have a lot of log files generating by the system (ucx) and other applications.
Therefore the version limit of 32,767
is reached quite frequently. The questions:
After the file version limit has been reached, would the UCX or other
application continue working well after failing to generate its log file?
The Answer is :
Some applications will automatically roll the log file version number
over, and some will require manual intervention. Some will continue
to operate without a log, and some will be unable to continue. Some
sites will specifically create a version 32767 to prevent the creation
of additional log files, too.
Given the environment, the OpenVMS Wizard would encourage monitoring
file version numbers and would encourage contact with the organizations
supporting the particular applications generating the files with the
rapidly-increasing version numbers for details on potential problems
and any recommendations on resetting the version numbers. If required.
The following pair of DCL commands -- though obviously subject to timing
windows -- can be used to rename all the versions of a file back down
to a contiguous sequence of versions starting at 1:
$ RENAME file.typ;* RENAME.TMP;
$ RENAME RENAME.TMP;* file.typ;
The key is the trailing semicolon on the second parameter.
You can use DFU (Freeware) to quickly and efficiently scan for all files
with large(r) version numbers:
For best results, selecting temporary or log file filenames from among
a set of filenames -- selecting filenames based on time, on process id,
on the day of week, week number, or month, etc -- is often useful, as
this approach more easily permits on-line adjustments to the highest
file versions and easily permits on-line version compression using
techniques shown above. With differing filenames, you are less likely
to encounter errors resulting from files that are currently locked.