[Info-vax] Large mailboxes

[Dave Froble]

On 12/4/2020 11:22 AM, Michael Moroney wrote:
> 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?
>

It begins with a fundamental design issue in RMS, at least in my opinion.

Data records in an RMS indexed file are ordered by the primary key. 
Thus any activity that adds or deletes data records must affect that 
ordered location.

Then secondary keys are not on a one to one correspondence with data 
records, but rather one key for each unique key and a list of pointers 
for each data record with the same key value.

I've disliked this design from when RMS was first introduced on the 
PDP-11 systems.

In the competing database I've been involved with, with design going 
back to 1974, each data record has unique key records for each key 
structure on a one for one basis.  I have found this to be much more 
flexible and efficient.  Perhaps that's just my opinion.

But consider, in RMS, when the primary key changes, that is actually a 
delete and re-add of the data record, not just a delete and re-add of 
the key record.  Keys are normally small, a data record can be quite large.

Would I use either of them in a new product?  Most likely not.  A RDBMS 
today works well with new fast hardware, and  is both standard (sort of) 
and flexible.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486