[Info-vax] VMS version numbers, was: Re: DCL enhancements

[Phillip Helbig undress to reply]

In article <rusbmg$sn5$1 at dont-email.me>, Simon Clubley
<clubley at remove_me.eisner.decus.org-Earth.UFP> writes: 

> On 2021-01-27, VAXman-  @SendSpamHere.ORG <VAXman- at SendSpamHere.ORG> wrote:
> > In article <388edf53-8ba9-4f66-aa86-00e6c6b1be4bn at googlegroups.com>, Jon Pinkley <jon.pinkley at gmail.com> writes:
> >>
> >>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.
> >
> > Purge and rename them back to start at ;1.
> 
> Which still gives you application failures if you don't catch it in
> time and application downtime while you apply this fix.
> 
> I wonder how much effort would be involved in adding support to VMS
> to automatically shuffle down the existing file versions when something
> tries to create a new version after ;32767 is reached on a file ?

Be careful what you wish for.  It is bad enough reaching ;32767.  
Imagine a runaway application.  With ;32767, at least it stops.  With 
reshuffling, it won't, and there will be the overhead of reshuffling.

> BTW, does anyone know how versions will be handled on the new filesystem ?
> 
> Will versions still be supported and if so, will they still be 16-bit
> version numbers or will they be increased to at least 32-bits ?

I really don't think anyone needs 32 bits here.  Yes, I know that Bill 
Gates once said that 640k RAM should be enough to take us into the next 
millennium (i.e. the one we are in now), but not everything increases 
with time (as the actress said to the bishop).