Discussion:
Queue entry numbers
(too old to reply)
Chris Townley
2024-04-18 19:24:02 UTC
Permalink
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

Any ideas?
--
Chris
Arne Vajhøj
2024-04-18 19:35:16 UTC
Permalink
Post by Chris Townley
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
Chris Townley
2024-04-18 19:39:20 UTC
Permalink
Post by Arne Vajhøj
Post by Chris Townley
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
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
--
Chris
Dave Froble
2024-04-19 01:50:39 UTC
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Chris Townley
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
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
Chris, are you somehow re-inventing the queue manager file? I forget the
details, it's been a while since I needed them. Check your system startup
command files.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Chris Townley
2024-04-19 12:12:51 UTC
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Chris Townley
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
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
Chris, are you somehow re-inventing the queue manager file?  I forget
the details, it's been a while since I needed them.  Check your system
startup command files.
No I have double checked. No restarted the queue manager/new, and no
queue inits
--
Chris
Stephen Hoffman
2024-04-19 22:41:17 UTC
Permalink
Post by Chris Townley
Post by Chris Townley
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
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
Loading...