[Info-vax] Mailbox driver analysis regarding greater than 65535 messages in mailbox

[Stephen Hoffman]

On 2020-12-01 17:42:29 +0000, Marc Van Dyck said:

> Hein RMS van den Heuvel submitted this idea :
>> But still they can keep writing and reading peaking above 64K messages 
>> only getting a non-success status when the mailbox is empty. Correct? 
>> If so, IMHO that behaviour should not be willingly broken.  Maybe an 
>> alternate success status, but even that could break applications 
>> testing for status == SS$_NORMAL.
>> 
> 
> No. If you look at the test I described in my original copy, you can 
> write any number of messages you want, but you can't read them all 
> back. The next time that the message count 16 bits field gets back to 
> zero, the read operation returns an "end of file" status and the 
> messages still remaining in the mailbox become inaccessible. In my 
> test, I stored 1.000.000 messages, but could only read back some 16.000 
> of them.
> 
> I would also agree with the proposal to refuse the creation of a 
> mailbox with more than 65535 positions.

Seems there's a bug here, based on the reported behavior.

That count-messages-and-reject fix will work. ADAWI, etc.

So too will fixing the API and simply, well, lying API callers, err, 
redefining and documenting that 65535 is now used as "many" in this API 
as is common with some other OpenVMS API hackery

For status updates where the latest update is the one that matters, 
I'll repeat my earlier reply that using mailboxes is ill-suited. For 
status messages and performance counters and ilk, a lossy LIFO is 
appropriate, and mailboxes are currently a somewhat-buggy FIFO. UDP and 
DTLS are choices for that, SNMP messages, RedFish, etc.  Hmmmm, haven't 
seen SNMP on the roadmap, and SNMPv2 is somewhere between stale and 
insecure, and OpenVMS SNMP is far too mixed up with the morass that is 
SMH. But I digress.

Or it's possible here write a mailbox driver that follows the mailbox 
model you want, and that implements LIFO. This is a pseudo driver and 
lacks hardware and any need for an interrupt context, which reduces the 
effort involved for the design and operation and debugging.

Thee's also the OpenVMS Zabbix client around, and a client for Nagios. 
This if the remote display already works with SNMP or Zabbix or Nagios 
or ilk.


-- 
Pure Personal Opinion | HoffmanLabs LLC