• Re: Queue entry numbers

    From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Chris Townley on Thu Apr 18 15:35:16 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to All on Thu Apr 18 20:39:20 2024
    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

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to All on Thu Apr 18 20:24:02 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to Chris Townley on Thu Apr 18 21:50:39 2024
    On 4/18/2024 3:39 PM, Chris Townley wrote:
    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


    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: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to Dave Froble on Fri Apr 19 13:12:51 2024
    On 19/04/2024 02:50, Dave Froble wrote:
    On 4/18/2024 3:39 PM, Chris Townley wrote:
    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


    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Hoffman@21:1/5 to Chris Townley on Fri Apr 19 18:41:17 2024
    On 2024-04-18 19:39:20 +0000, Chris Townley said:

    On 18/04/2024 20:35, Arne Vajhj 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)