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

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

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

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

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

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