Batch Queue entry numbers

[Aaron Lewis_1]

We recently upgraded from Alpha VMS 7.3 to Integrity 8.3. Under 7.3 the queue entry numbers would go up to 1000, then roll over and restart at 1. After just a few weeks in production the 8.3 entry numbers are over 2,000,000. Our process calls for monitoring some jobs by their entry number, Is there any way to restore the 7.3 behavior, or set an upper limit that will force the numbers to roll over?

[Walter Miller_1]

This was pretty much covered in the following

http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1209649011045+28353475&threadId=1144436

[Jan van den Ende]

Aaron,

this has NOTHING to do with any VMS version (at least starting V5.5).
Whenever the number of entries exceeds 999, then the available number range flows over to this much bigger number (of which not all numbers are used, btw).

Entry numbers are to be considered as just that: unique IDs _WITHOUT_ any additional meaning (at least, NOT to be used nor controled).

Your changeover happened because at some moment your number of entries (active, waiting, and retained, all counted) was bigger than the small set could handle.

Proost.

Have one on me.

jpe

[Hoff]

Summary of previous discussions follows...

Batch Queue entry numbers should be treated like process ids; as PIDs.

Best to assume the job entry number (or the PID, for that matter) is simply an opaque longword.

That the entry numbers are often assigned in somewhat recognizable sequences was arguably a small design mistake in my view, as it led to assumptions that should not have been made.

Like the PID and its internal structuring (and ignoring topics of IPID and EPID), the current format of the job entry number (and this is subject to change) is comprised of several bitfields; the entry number contains the queue manager number and non-contiguous fields that together contain an ascending value.

When last I looked, the internal structure of the entry number was XYYXXXX, where X is a field containing a zero-suppressed entry sequence number, and YY is the queue manager number. In hexadecimal. Subject to change.

There have been changes to the queue manager to try to drop this entry number value back down to small positive integers, but that's not entirely reliable -- the values can spike back up into the "weird" ranges and "weird" values when certain thresholds are crossed, and when certain queue configurations are instantiated.

[John Gillings]

Aaron,

No you can't adjust the wrap points. Entry number ranges expand as required by the number of jobs submitted. If you have software that doesn't like larger entry numbers, you should fix it. The entry number can be any 32 bit signed integer. Any software that can't handle the entire range is incorrect.

I've found that even as far back as V7.3, the queue manager is very good at restoring entry number ranges, as long as the jobs get cleaned up. Perhaps someone has turned on retention on a queue? Or there was a peak which exceeded 10K jobs - maybe a runaway self submission? You may also find that an overzealous job monitor executing many F$GETQUI or SHOW QUEUE commands will keep the queue data base so busy that the queue manager doesn't get a chance to clean up old entries fast enough. This can artificially keep the entry range higher than expected. Once you're in the extended range, you have to wait for a complete cycle of jobs.

Here's a procedure I've used to correct self submission accidents which have flooded a queue with multiple copies of the same job:

$ loop:e=F$GETQUI("DISPLAY_ENTRY","ENTRY_NUMBER",p1,"WILDCARD")
$ IF e.NES.""
$ THEN
$ DELETE/ENTRY='e'
$ GOTO loop
$ ENDIF

(avoid manipulating jobs while this procedure is running, as it may interrupt the GETQUI context and stop the job. Don't include any WRITE commands in the loop, as they'll slow it down by an order of magnitude or two)

If you really need to cycle the numbers, here's a procedure to submit and delete jobs until the entry number is lower than a specified value.

$ IF p1.EQS."" THEN EXIT
$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
$ loop:
$ SUBMIT/HOLD 'self'
$ DELETEX/ENTRY='$ENTRY'
$ IF F$INTEGER($ENTRY).GT.F$INTEGER(p1) THEN GOTO loop
$ EXIT

(beware that for some queue manager configurations and values of p1 this is an infinite loop!). Also beware that both the above procedures keep your queue manager very busy while they're running so things like SHOW QUEUE commands may run very slowly. They may work better/faster if executed on the node running QUEUE_MANAGER.

[The Brit]

Aaron,
Although your post only references Batch Queue entries, I'm sure you know that the entry numbers are shared by all of the system queues, particularly printer queues.

John touched on the primary culprit in these situations, i.e. print queues set to RETAIN, or queues which are STALLED or STOPPED.

The Queue Manager cannot reuse an entry number as long as it is assigned to a job in a queue, and although it is obviously possible for a system to be legally handling large numbers of entries, i.e. batch jobs can be legally in a "holding" state for long periods of time, entry numbers assigned to print jobs should, in general, only be tied up briefly.

When the numbers jump from 4-digits to 7-digits, this often means that a busy print queue has been stalled or stopped for a significant period of time, or that someone has set a queue to RETAIN (perhaps for testing) and forgot to remove it when done.

Dave.