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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)