OpenVMS 8.2 Job entry numbers are very large

[Gerald Deinzer]

I have notices that recently. since the OpenVMS 8.2 upgrade, the entry numbers have taken on a new characteristic. They now are 7 digits as opposed to the four I am used to seeing. What gives? Ex.

Batch queue T4$BATCH, busy, on PRKY::



Entry Jobname Username Status

----- ------- -------- ------

3002761 T4$COLLECT SYSTEM Executing

[Steven Schweda]

Did you read the release notes?

Did you try a Forum (or comp.os.vms) search?


Why do you care?

[Jan van den Ende · Accepted solution]

Gerald,

please learn to see job numbers as just that: _A_ number. WITHOUT any coded-in properties.

If you set up a VMS queueing system, the range of numbers is (IIRC) 1-1999 (or 1-2999, sorry not sure there.

If, at ANY time, for ANY reason, the need(usually the total of print and batch jobs, waiting plus executing plus retained) exceeds the avalable slots, or if you ever have/had multiple queue managers active, that number is not enough, and the range gets extended to 7 digits, with larges holes in the range.

PLEASE consider it "just another number"

hth

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

It means that you had at 1 moment more than 10.000 entries in the queue.

First you have 999 entry numbers. When that's all used, it jumps to 9999. And then to 9999999 (starting with 1000000).

It's not a problem but indeed confusing. Reboot when all entry numbers are below 999 and it will start again with 999 entries.

Wim

[Jim_McKinney]

> Reboot when all entry numbers are below 999 and it will start again with 999 entries.


???

[Hoff]

Recent OpenVMS versions do try to compress the range of job entry numbers down, but (like the old PID "panic" that arose back when clustering added a field to the PID and PID values went from simple to not simple) these batch queue entry numbers should simply be treated as opaque longword values.

In retrospect, it was a arguably mistake to use an obvious sequential allocation algorithm and to keep the numbers in a small range up until they teleported off into a scary gigantic and more-typing range. (A case of setting user expectations wrong. When designing and if you have to do this design, always start with the "scary value.")

The job entry number is officially undocumented, but there are descriptions of the fields around -- just like there are descriptions of the organization of the external PID value.

Here's some reading material, including the format and a now semi-documented mechanism to compress the queue entry range:

http://64.223.189.234/node/419

[Wim Van den Wyngaert]

> Reboot when all entry numbers are below 999 and it will start again with 999 entries. ??

If job numbers get above 1000000 (or 999), remove all jobs (and reshedule them later) or make sure that all job numbers are below 1000 and reboot. The cycle between 1 and 999 will restart.

Wim

[Gerald Deinzer]

Thank you very much. After some of the suggestions, I reviewed the print queues and discovered that Oracle's Enterprise Manager had submitted thousands of print jobs to sys$print which has been stopped on this node. After I emptied the queue and closed it, the entry numbers have remained below 1000. Thanks again!