[Info-vax] DCL enhancements

[Simon Clubley]

On 2021-01-26, Jon Pinkley <jon.pinkley at gmail.com> wrote:
> On Monday, January 25, 2021 at 12:05:38 PM UTC-5, Stephen Hoffman wrote:
>> 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. 
>
> Hoff, I am tempted to ask if there is anything about VMS you do like.
>

Not Stephen, but for me, I like VMS clustering. Its UI is a product of
the age it was created in unfortunately, but it's only over the last
decade or so that other operating systems have come close to matching
it in functionality when you need a shared-everything cluster with
multi-site disaster recovery instead of one of the massive loosely-connected
clusters of compute nodes with little shared context.

> And setting the version to one is really an autopurge, it still creates new 
> version numbers that will eventually get to ;32767 and then possibly cause
> problems.  The point is ODS is not NTFS or some unix/linux versionless file
> system.  And there are many vms applications that rely on versions.
>

How about modifying VMS to do _optional_ wraparound of the version number
if it hits 32767 ?

The downside is that your latest version does not have the highest version
number so there will be major problems if you try to open the file for read.

The upside is that your application continues working if it is only creating
write-only files such as log files.

BTW, if you have a version limit of 1, the ;32767 version will be
automatically removed if this is implemented and replaced with a ;1 version
so that _would_ become the highest version.

Another option is for VMS to implement version shuffling so all the files
are shuffled down a version when ;32767 is reached and a new version is
created. That would incur major overheads, especially given the amount of
locking that could require, but the application would continue working.

I wonder how difficult it would be for either of those options to be
implemented ?

> I agree there are many things that could be done better than the way that 
> VMS does things.  My pet peeve is how much user involvement is needed for 
> updating and trying to determine dependencies. windows and linux make 
> that much easier and less error prone.
>

Dependency management is a _major_ weakness for VMS in today's world.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.