queue job entry number

[wendling]

Hello,
The job numbers in print/batch queues raised untill 1000 and then restarted with 1, but now they continu above (now 1200)without any change in the system.
How can we explain or control this behavior? (vms 7.3)
Thank's in advance.
gerard

[labadie_1 · Accepted solution]

Bonjour :-)

The job entry number is an opaque longword value, so do not worry, they will roll back to 1...later.
As it is a longword, you could get 2 or 4 billion entries :-)

You can't predict what will be the next entry number, 1201 may or may not be the next entry number after 1000.

No risk of two entries with the same entry number, by the way.

PS: So you have left S....

[Uwe Zessin]

Looks like you once had more than 1000 entries in which case the counter will wrap (used to wrap in older VMS releases) around at 2000.
And you don't have multiple queue managers in which case some upper bits would get used.

But I agree with labadie:
don't try to understand how it works. As you can see, it can change at any time and it is not documented.

[Wim Van den Wyngaert]

Read this too
https://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=992108

(it's good to have a name containing wyngaert. Google immediately finds my stuff)

Wim

[wendling]

Thank's to all!
Now it's more clear to me
Gerard

[Hoff]

From the FAQ:
--

13.7 How can a batch job get its own batch entry number?

To have a batch procedure retrieve its own batch entry
number, use the following:

$ Entry = F$GETQUI("DISPLAY_ENTRY", -
"entry_number","display_entry","this_job")

Remember that the entry numbers issued by the OpenVMS
Job Controller are always opaque longword values. Do
not assume you know the format of the entry number,
nor the range of entry numbers you might see, nor the
algorithm that is used to assign enty numbers. You
should simply assume opaque longword.

--

I'll tweak the section to better explain the details and the (lack of) a published algorithm. And that there have been changes to the internal algorithm. In retrospect, it was probably a bit of a UI mistake to have the first entry be "1", etc. Had it looked like a PID...

[Uwe Zessin]

> Had it looked like a PID...

Didn't the OPCOM request numbers change the other way round?

I have a dim memory that we first had some arbitrary numbers which later (VAX/VMS V5?) was changed to start by one and then just increment.

[Hoff]

The PID used to be rather more sequential, and things PID really shuffled around when clustering arrived. There was the old PID, which is now basically the IPID or Internal PID, and the "new" external or EPID PID. And there are fields of variable width within the PID/EPID.

The classic PID had a re-use count and a slot number. (And very similar to the file system FID scheme, I might add.)

The new PID stuffs the cluster node into the PID, too.

The batch queue entries can have some interesting jumps; there are some big jumps that can occur, far beyond what you might expect for a sequential algorithm -- there are some big jumps when you have multiple queue managers around.

In the current (circa V8.3) queue manager scheme, the values are bit-fields. If you're seeing stuff with small entry numbers, then the queue manager configuration is a simple one.

Schemes can change, as the folks using knowledge of the old PID had discovered eons ago. There was at least one third-party product around for OpenVMS that had always assumed the job entry would fit in a word too, even though all the documentation had indicated it was a longword, for instance.

As I've been quoted before, "it's an opaque longword". Don't assume... The particular scheme may never change, or it may change in the next ECO.