[Info-vax] Large mailboxes

[Jan-Erik Söderholm]

Den 2020-12-02 kl. 22:26, skrev Dave Froble:
> On 12/2/2020 12:38 PM, Michael Moroney wrote:
>> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm 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?  That is one process can write records in order, a second
>>>> process can read and delete records in order, without RMS cruft from
>>>> accumulating?
>>>>
>>
>>> It depends on the definition of a "VMS file". I see no issues with having
>>> an Rdb table as the buffer.
>>
>> I kind of meant RMS file, something accessed via RMS $GET/$PUT/$DELETE or 
>> their
>> high level equivalents.  I know if just disk space anything could be used.
>>
>>> Is there an indication on what "a fairly large number" of messages is?
>>
>> Maybe 6000 messages/day, it could vary quite a bit.
>>
> 
> I believe I mentioned linked lists earlier.
> 
> If you desire to use an RMS file, a relative file could easily be used for 
> a linked list.  Multiple ways to design it.  One might be a file with say 
> 10,000 records, where part of the data is a link to the next record in the 
> list.  Could have reverse links also.  Have two lists, a list of unused 
> records, and a list of records with active messages.  Use simple logic to 
> pop the next available unused record for use, and to add a used record back 
> to the list.  Front or back should not matter. Always add new messages at 
> the end of the list of messages.
> 
> Really simple, really quick, no cruft, ....
> 
> Considerations:
> 
> If the list needs to be persistent, use record 1 for the list pointers. 
> Otherwise keep the pointers in memory.
> 
> No reason there cannot be more than one message list.
> 

Still much more application logic than a simple SQL INSERT... from one
application and SQL SELECT..., <process>, SQL DELETE... from the other.