Queue Entry Numbers

[Duncan Crichton]

How do I change the maximum number of queue entries beofor it goes back to 1. At present the entries only go up to 999 before reverting back to 1

[Wim Van den Wyngaert]

Only by a reboot.

Wim

[labadie_1]

You do not have to care about it. The entry number is a opaque number, if it needs to go beyond 999, it will.

Do you have a real problem at the moment ?

[Duncan Crichton]

No this is not a real problem it was just that I noticed after the machine was rebooted the number never seamed to go beyond 999

[Art Wiens]

After a runaway resubmitting batch job, we have entry numbers that won't reset to a lower value, even after a reboot. They are "stuck" in the 10,000,000 - 10,009,999 range ... quite "unnatural" to look at, but it's caused no "problem" so far ( a couple of months).

Cheers,
Art

[Jan van den Ende]

Duncan,

to begin with:

WELCOME to the VMS forum!

Qute question.henever this issue came up before, it was the other way around: people having trouble with the high numbering.
But you really do NOT need to worry about scarseness of entry numbers. Whenevr there are no free entry numbers, the list gets extended (as in extended BIG TIME!).

Just treat it as an ID, with NO open or hidden implications oyjer than uniqeness, which starts with a restricted set, but with the ability to expand at need.

hth

Proost.

Have one on me.

jpe

[Jess Goodman]

Jan gives good advice. A reboot would have no effect on the entry numbers.

[John Gillings]

Duncan,

Queue entry numbers look after themselves. The range will expand when and if necessary, so if you never have more than 999 simultaneous entries, the numbers will just cycle 1-999. Once you get your 1000th simultaneous entry the range is expanded. Apart from the first few jumps, the pattern of expansion is reasonably complex, undocumented, and subject to change, so there's not a lot of point in trying to figure it out. Just trust that the system works.

When storing or manipulating entry numbers don't make any assumptions other than it being a 32 bit integer that uniquely identifies a particular entry.

Regarding Art's problem (runaway expansion giving very large numbers), If the big numbers offend, you can "fix" them by cycling entries yourself. Something like:

$ loop:
$ SUBMIT/HOLD SYS$LOGIN:LOGIN.COM
$ DELETE/ENTRY='$ENTRY'
$ IF F$INTEGER($ENTRY).GT.999 THEN GOTO loop

Once you've got the entry number into the range you want, and all the high entry numbers are gone, the queue manager should revert to the smallest range that will contain all existing entries.

The impatient may want to force the issue with:

$ MCR JBC$COMMAND
JBC$COMMAND> DIAG 7

[Art Wiens]

John, unfortunately neither of those two suggestions have resolved our "issue". I think the queue manager crashed ~12 times before anyone was notified. It didn't cope well while trying to handle ~14,000,000 entries! It's "hooped". ;-)

Like I said, I don't think there's any recourse but to "start again" - delete the database and redefine all our queues, forms, characteristics and resubmit all holding jobs. Not a task I look forward to, but for now it still works.

The DIAG 7 did reduce the size of the journal file after those 14M entries got deleted.

Cheers,
Art

[Duncan Crichton]

As this is not really a problem I just wanted to know if I could changed the Entry number range I believe this question has now been answered

[Barry Alford]

I am intrigued by:

$ MCR JBC$COMMAND
JBC$COMMAND> DIAG 7

What does this do?
Is it documented?

[Art Wiens]

Do a:

$ dir/size=all SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$JOURNAL;1

If it has a large allocation, a:

$ mcr jbc$command
JBC$COMMAND> diag 7

will (should) do a bit of housekeeping and reduce the journal file allocation (sometimes). I believe it's ability to do this is reduced by the number of current jobs in all their various states (holding, pending, executing, retained etc).

I have found very little info on JBC$COMMAND ... mostly just folklore in forums ;-)

Cheers,
Art