[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