[Info-vax] Queue entry numbers

[Stephen Hoffman]

On 2024-04-18 19:39:20 +0000, Chris Townley said:

> On 18/04/2024 20:35, Arne Vajhøj wrote:
>> On 4/18/2024 3:24 PM, Chris Townley wrote:
>>> Much to my annoyance, mu X86 VMS instances insist on resetting the 
>>> queue entry number to 1 after a reboot, rather than carrying on where 
>>> it left off
>>> 
>>> I remember sorting this in the past, ISTR when we set up the I64 
>>> machines, but cannot find anything in my notes, nor in the docs
>> 
>> Not an answer but two questions:
>> 1) Why? Shouldn't entry number be sort of just identifying without any 
>> meaning to value?
>> 2) Have you considered what will happen when max is reached?
>> 
>> Arne
> 
> Not really a problem, but it confuses me!
> 
> ISTR that if you didn't use  too many, it rolled at 999, but if you had 
> many it extended to 4 digits, as it did on our work machines, then 
> rolled at 9999 which carried on

Oh, wonderful, I can dredge up this ancient detail...

Queue job entry numbers are opaque longword values.

The assigned queue entry number is unique over the lifetime of a job entry.

While a queued entry can persist over reboots, a queue entry number is 
not unique over the life of a running system or cluster.

The existing queue entry number algorithm design is quite effective at 
causing developers to acquire misleading or incorrect inferences about  
the entry allocation order.

The queue entry number allocation order is undocumented, and has 
surprises as queue managers are added and as numbers of concurrent 
entries increase.

It'd probably have been better if the initial queue entry numbers were 
at least somewhat randomized, as that'd reduce the assumptions and the 
ensuing mistakes.

One of my favorite developer mistakes has been a word-length entry 
number storage field in an app, because the developer made some 
mistaken inferences, and/or had never seen larger values.

That mistake has become less common as memory has gotten cheaper and 
developer preferences for VAX-ish data packing have waned.

Within the current implementation, the limit is 99,999 simultaneous job 
entries for each queue manager running and up to five queue managers, 
IIRC.
In the current (undocumented and subject to change!) algorithm, the 
queue manger likes to stay within and wrap within four decimal digits, 
but will add two more digits for the queue manager number (of which up 
to 5 are implemented) and adds two more digits to extend the queue 
entry range.
I don't know off-hand if a queue diagnostic was implemented to reset 
the queue database size (akin to JBC$COMMAND DIAG 7), but the classic 
way to compress the database was to drop down to one queue manager and 
re-create the queue database.
Similarly, PIDs are also best considered opaque longwords.  "Modern" 
PIDs at least fill more of the opaque longword, so the range 
assumptions are much less common.

Related: https://forum.vmssoftware.com/viewtopic.php?t=6332


-- 
Pure Personal Opinion | HoffmanLabs LLC