[Info-vax] Large mailboxes

[Dave Froble]

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.
>
> For busier files, if you can, try NOT to just read the file from the beginning in the loop as you may have to wade through empty buckets. Use greater than some last-read PK value instead - stashing a high PK away once a day if desired.
>
>> 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.
>
> Sure Dave, but for a double linked list there are several writes involved

That sort of depends upon the design.

> and for a single linked list you may have to scan for a while to find the end to add to it.

Not if you have begin and end pointers for each list.  If actually 
searching the list, yeah, going from node to node will require reading.

> There again some last read pointer stashed away may help.
> Relative files typically need a special tool to maintain/analyze them as system provided converts and re-creates do not work.

As far as I know, relative files do not require maintenance.

My 40 year+ old messaging system uses Virtual file type and one disk 
block for each message, but, that is a rather complex utility.

> Typically there is a desire for an initialized master records, and links with record numbers are lost on covert.

No CONVERT required.

> I case of trouble you'll have some serious dumping and debugging to be done versus a simple type or dump/record
>
> Now for the original question (Marc's) replacing mailboxes the reads are destructive.
> Once read there is no going back and there should be no gaps.
> For that a relative file or just a fixed length sequential file could work with some round robin scheme allowing for the max outstanding records. To avoid reading from the beginning all the time just use a simple master record with a sloppy last read record number. Update that only every 100 or 1000 reads and when hitting the configured max of course. When updating be sure to add the current time, process-id and process name. With a little extra work update a little last-5 updates array allowing one to look back and see how often it goes around and what the write rate is per 1000 messages or whatever interval chosen. btw ... Go ahead waste a few more bytes and make the header row and stash readable, not binary, for your own comfort. You have my permission :-).
>
> Cheers,
> Hein
>


-- 
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