>Hi! Has anyone found a fix for the annoying behavior of
>RMS indexed files that don't release their empty buckets.
That's not a bug... it's a feature. Seriously, It is working as the RMS design
intended and as such will never be 'fixed'. One of the reasons for this is to
keep record delete operations relativly simple and thus cheap.
Removing a bucket involves updating an index bucket, and the bucket logically
prior to it as they both contain pointers to it. There is no back pointer to
either. (fwiw, Relativly recently (VMS V6.1) RMS has added 'READ REVERSE'
which does solve both problems, but it _still_ seems too much trouble to
do something similar for cleanups, notably dues to complications with
duplicate chains).
>Short of rebuilding the file or doing a reclaim, what can I do ?
RMS _will_ reuse the space freed up by deletes for records in the
same key range FOR THE PRIMARY KEY. So if the file for example is
a daily to do list, with records coming in for the future hours
on future days, and records being deleted for past times, then it may
be good enough to DROP the month or year part from a date/time primary
key definition (just the key layout, do not change the data in the record)
thus records for this month can start yo take up space deleted last month.
It might mean SWITCHING primary and alternate key, or truncating a job
number to round-roubing through a fixed (large) set versus constantly
handing out larger and larger numbers (compare with VMS batch job entries).
>Is there any way of reclaiming with users still
>working on the file ? We are in a real time environment
>and we can not halt the system for more than 1 hour.
(calleable) Convert/reclaim is there precisely to solve this problem.
It does require exclusive file access, so the application (not the whole
system) must be shut down. Hopefully only a few minutes would be needed,
and possibly other manintenance activities can be done in the same window.
Rebuilding the file using (calleable) CONVERT may well be desirable anyway.
It might not be all that much slower than reclaim, as both need to read all
buckets anyway. Maybe, just maybe, you can CONVERT/SHARE the file whilest
allowing ongoing access, then take down the application for seconds to switch
the old and new files, and have a specialized process resolve the
inconsistencies due to updates while the files was being converted (reading
both new and old file in parallel and updating/insering as needed).
For some applications it may be worth their while to streamline this
completely by having a file access module, driven be a lock, which knows
whether a file is 'open for business' or whether it is only there for
reads, relegating modifications to an intermediate transaction log while
a convert (or backup) is tacking place.
> Is this a future feature for VMS ?
There are currently NO plans to add any form of dynamic reclaim to RMS.
