[Info-vax] Large mailboxes

[Michael Moroney]

On 12/3/2020 11:41 AM, Hein RMS van den Heuvel wrote:
> On Wednesday, December 2, 2020 at 4:27:03 PM UTC-5, Dave Froble wrote:
>> On 12/2/2020 12:38 PM, Michael Moroney wrote:
>>> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.... at telia.com> writes:
>>>
>>>> Den 2020-12-01 kl. 21:02, skrev Michael Moroney:
>>>>> So in theory, is it possible to implement a VMS file as a FIFO and work
>>>>> efficiently?
> :
>>> Maybe 6000 messages/day, it could vary quite a bit.
>
> For Michael's 6000 message/day case, where the reader can likely keep up with the writer (unless writes are in bursts, or reads can be stalled), an indexed file with a largish bucketsize able to hold the normal maximum of outstanding records  is an easy solution.
> Just refresh every month or every year or so.

This problem appeared since the portion using this method was running for quite 
some time (well over a year) and someone noticed a process was using loads of 
CPU or disk IO (maybe both) and wondered why a trivial process was using so 
much. It was tracked down to the very old file.  I was tasked with finding out 
what was going on and to fix it but not spend much time on it.  I was surprised 
to find a huge but empty file, and pondered what the proper fix was (appears 
the easiest is using a relative file which I knew little about)  The final 
"fix" was a DCL procedure to replace the file with a fresh one during 
"maintenance" times.

Again this is from a previous job, nobody worry about this beyond a "how to get 
VMS to do X the best way" amusement puzzle. It just bugged me that simple 
repeated RMS put/get/delete sequences worked out like this. I initially 
searched for some RMS incantation for a FDL file. But I didn't know the 
difference between an RMS bucket and a pail.

Is there a reason why the equivalent of CONVERT/RECLAIM can't be run for one
bucket only when it becomes empty/unusable?