[Info-vax] DCL enhancements
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Mon Jan 25 12:05:34 EST 2021
On 2021-01-25 13:40:25 +0000, Phillip Helbig (undress to reply said:
> What about some easy-to-implement DCL enhancements?
>
> With PURGE/CONFIRM, there is Y, N, and A. Why not R, for "rest", which
> would be A but only for the current file name and extension, then it
> would ask again for the next one?
Or set the default version limit to one on all volumes newly
initialized, maybe fix the inexplicable SYS$SCRATCH default of
SYS$LOGIN, and force the user to enable and accept the costs and messes
of multiple versions manually.
Then force the user to deal with the ensuing complexity brought by
their unwise choice to enable multiple versions, to script the
inevitable cleanup requirements, to store their temporary files in an
actual temporary area, and not dump all that into SYS$LOGIN:.
The forward-looking and overly-complex design—avoiding this mess—would
integrate replaced versions with backups and with a backup data
recovery framework, so that the superseded versions are immediately
gone, but are also archived and available to restore. This might work
better with newer file systems that are not infested with versions, but
would need file-change notification support and work in BACKUP or its
replacement. This'll need some change-pruning support, obviously. Maybe
all copies for an hour, then hourly copies for a day, etc. Pretty soon,
you will have built your own time machine for saving and restoring
files.
But then designing a mostly-secure temporary storage area might require
a little more thought than initially realized, too. Same for backup and
restore integration. And compressing the delta for the
version-to-version changes is certainly fodder for thought.
Put differently, I don't encounter this PURGE case often enough to be
interested in [R]EST, as I prefer to fix the accruing-versions problems
as its encountered. Whether by automated and targeted purges, or by
shutting off versioning, or by fixing the app. And I'm aware of very
few cases that handle ;32767 without assistance (DECnet-Plus logging is
one of the better-known), and that handling can need adjustments
if/when the version limit is expanded to ;65535. Most other stuff
around either uses ;32767 as a way to (implicitly) disable some
file-creation mechanism, or it tips over. That RENAME
version-reset-version-packing command sequence (
http://hoffmanlabs.com/vmsfaq/vmsfaq_011.html#mgmtversions ) should be
(better) highlighted in the manual, though.
Or sure, add [R]EST to the standard qualifier stuff. This is OpenVMS,
and we adore adding complexity and more knobs and more arcana. And with
leaving users with piles of stale versions, necessitating cleanups, and
the inevitable debates among the proponents of versions and the
proponents of other solutions that preferably avoid adding more load
onto the developers and system administrators.
ps: See
https://vmssoftware.com/docs/VSI_UTIL_ROUTINES_MANUAL.pdf#page=63 and
UTIL$CQUAL_CONFIRM_ACT, etc., for those unfamiliar with what JR
referenced around the common qualifier package. Most of that got
documented a while back.
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list