Queue entry numbering

[Wim Van den Wyngaert]

I was doing some testing and found that
when there are 970 entries in the queue when the counter reaches 999 it will NOT reuse the empty slots (at 930 it did).
When the counter runs in a loop of 3000, it checked reusage of more than 1000 entries so the number 970 isn't fixed.

Does anyone knows the exact algorithm of this looping/reusing ?

Wim

[labadie_1]

Hello

>>>Does anyone knows the exact algorithm of this looping/reusing ?

Yes, Vms engineering :-)
Seriously, it is not documented, it is an opaque number, just treat the entry number as a number which can be big (we have entry numbers like 1003256 on a Vms node) or less (we have a lot between 500 and 2000, on the same node).

What do you want to achieve ?

I think a bad idea would be to try to guess the next entry number when a job (batch or print) is submitted.
And, by the way, you know the next entry number, after a $ submit or $ print,

entry='$entry

[Wim Van den Wyngaert]

Achieve ? Nothing but understand how it works. I'm pretty sure that we never had more than a few 100 entries but the cycling moved up.

[Wim Van den Wyngaert]

No longer that sure. An antry from above 1000 could have been present when we rebooted.

If found that searching the free holes is not always executed (7.3).

Wim

[John Gillings]

Wim,

Be careful you don't influence the results with observation. SHOW QUEUE, F$GETQUI, SUBMIT, DELETE/ENTRY and jobs terminating *will* affect locking in the queue data base, which can give illusory results - ie: entries may not be completely deleted, they're not visible from SHOW QUEUE, but can't be reused just yet. I've found that when the queue manager is kept very busy it seems to defer some operations to quieter times.

These aspects of queue manager behaviour are not documented and shouldn't be a concern to most users. Also note that I could be completely wrong, that's just what seems to be happening in fairly extreme cases (like removing 20,000 stray entries as fast as possible).

If you want to know the exact algorithm, you'll need to examine the sources, but since it's subject to change, there's not a whole lot of point trying to figure it out.

[Wim Van den Wyngaert]

Good point John. But I added 997 jobs (in hold) to a system with 1 job in the queue. The first entry number was 8 and the last was 1004. No effort was done to use the first 7 numbers.

Wim

[John Gillings]

Wim,

>The first entry number was 8 and the
>last was 1004. No effort was done to
>use the first 7 numbers.

Correct! If you've already expanded beyond the 0-999 range the next wrap point is 1999 (I think, doesn't really matter what the exact number is). So the queue manager will use 1000 and beyond.
There is no documented way to determine the current range of queue entry numbers, nor are the conditions under which the range will be contracted documented - just that it may happen from time to time. The conditions for expansion are obvious - no available entries. If you want to know more, get a copy of the source code.

As long as your software is written correctly, it should make no difference at all what entry numbers are allocated. There is no performance or resource penalty for having high ranges (unless they're caused by accumulation of excessive retained or otherwise unproductive entries).

Indeed, if the algorithm is adaptive, it might "learn" the pattern of job submission on your system and decide that contracting the range is an unnecessary overhead since your system typically lives in a larger range. That's not to say it *is* adaptive, but there are others in OpenVMS that are. Consider the allocation of security journal space. The system "learns" your typical usage and allocates space accordingly.

We just get back to what Gerard said:

"it is not documented, it is an opaque
number, just treat the entry number as a
number which can be big (we have entry numbers
like 1003256 on a Vms node) or less (we
have a lot between 500 and 2000, on the
same node)."

If you CARE about the exact value of an entry number you're doing something wrong, or have incorrect expectations.

In terms of your experiment. As I said earlier, I believe you may get different results depending on how busy the queue manager is while submitting the entries. So, for example, a tight DCL loop around your SUBMIT command, and/or concurrent SHOW QUEUE operations may be more likely to NOT contract the range, possibly because the queue manager can see a queue of waiting requests. Perhaps if you write your SUBMIT loop with a delay, you'll give the queue manager more time to stop and think about range adjustement. After all if you were the queue manager and you'd just seen 970 SUBMITs in very quick succession, would it be a good idea to REDUCE the range when the best estimate is that the flood of SUBMITs will continue (or even visible queued up at the time)?


Wim, I'd also remind you that the ITRC points system is intended to reflect the technical quality of the answer, not how much you like or dislike it. Gerard's answer is correct, it answers your question exactly, gives you additional useful information and an offer of more information given more detail of the actual problem. IMHO awarding him only 2 points is an insult to his effort in spending his time for YOUR benefit.

[Wim Van den Wyngaert]

John,

Gerard was indeed right but my question was "Does anyone knows the exact algorithm of this looping/reusing" and thus the info he gave didn't help me.

I waited some minutes before submitting the job that went over 1000 (in the next test) and had not been over 1000 before (queues empty and rebooted).

Wim

[Robert Brooks_1]

Other than curiosity, why do you care about the algorithm currently in use?


Now, it's highly unlikely that it'll change again (anyone remember VAX/VMS A5.* (as opposed to V5.*). The cluster compatibility issues make it unlikely to change, I'd guess.

Does your software have some dependency on entry numbers and/or ranges?

Yeah, I could spend 10 minutes or so and look at the source and figure out the algorithm, but I'm not sure that's a good use of my time, and I'm not sure how that would really help you.

-- Rob

[Wim Van den Wyngaert]

Just curious.