How to limit entry-numbers to max. 3 digits

[M.Pohl]

Our queue-entry-numbers (VMS V7.3-1) counts up to 4 digits. How can I limit the queue-numbers to 3 digits only.
thanks a lot for any help in advance

[Uwe Zessin]

You need to rewrite the queue system, really!

By default, job entry numbers cycle between 1 and 1000. Once you had more then 1000 jobs it starts cycling between 1 and 2000. And so on.

If you need to go back to 1..1000, I am afraid you have to reinitialize the queue database.

[Ian Miller.]

queue entry numbers are supposed to be treated as a opaque integer value, that is you are not supposed to make any assumptions about the range or sequence of values.

Why do you want do limit the entry number to 3 digits?

[Marc Van den Broeck]

If you make sure there is no pending or holding queue entry above 1000 and if you then reboot the system then it will again count from 1 till 1000. But as sson as you have more then 1000 jobs it will go after it again.
However if you use this number for something it WILL always pass the number 1000 which obviously is a 4 digit number.
So, as Ian suggested, you have to treat this number as an integer, not as a 3-digit number.

Rgds
Marc

[Robert Gezelter]

M.Pohl,

I concur, treating the queue entry number as anything other than an opaque integer will cause a problem sooner or later.

- Bob Gezelter, http://www.rlgsc.com

[M.Pohl]

Thanks all for the answers, but the problem is, the customer has a lot of scripts which ask the entry numbers only with 3 digits.
The customer dont like to chance all the scripts.
If I delete and create the queue,it will be start count with jobnumber 1?
Which is the best solution for the customer?
Or is there no way to change the scripts to 4 digits?
Thanks for help

[Uwe Zessin]

> Which is the best solution for the customer?

Theoretically, he *MUST* change his scripts to cope with the full 32-bit range (entry numbers can be larger than 4 digits - just start using multiple queue managers). Even if they were limited to 4 digits - they cycle between 1 and 1000, not 1 and 999. Using 3 digits is a design defect in his software and any workarounds will fail on one day.

[Volker Halle]

M.Pohl,


If I delete and create the queue,it will be start count with jobnumber 1?


deleting the QUEUE does not get rid of the problem, you would need to create a new queue database with START/QUE/MANAGER/NEW

This will create a new empty queue database and you'll have to create all queues and jobs again. If you are desparate enough to do this, make sure to do a SHOW QUE/ALL/FULL/OUT=x.x of your old queue database first, to document your current settings.

As others have already pointed out, the problem is in the scripts not being able to handle 32-bit unsigned entry numbers. Re-creating the queue database will only be a temporary workaround.

Volker.

[Jan van den Ende]

M.,

First,

WELCOME to the VMS forum!


Which is the best solution for the customer?
Or is there no way to change the scripts to 4 digits?


As others have pointed out, there really is no reasonable solution but modifying the scrips.
Just curious: How did the customer succeed in accumulating "lots of scrips" dealing with 3-digit entry numbers? Did those never de-rail?
More importantly: HOW are the 3 digits specified in the scripts? Do the use a standardised syntax, or are they specified in a number of different ways?
How easy or complex would it be to generate a list of all those scrips, and then, would it be possible to formulate an EDIT COMMAND file to do the changes?

Because, even IF you refresh your queue file regularly (and think of the complexities mentioned above!), even then you only need ONE application that spawns a print command and have that runaway ONE time (any kind of foolish user choice, for instance) and you entry numbers go into 8digits. I have seen it happen, but that is another story.

Really, however cumbersome it may be, you MUST convince the customer that it MUST be changed, or someday, at the most unwanted moment, weird unwanted things are bound to happen.
And if it helps to convince your customer, please show them this thread.

Good luck!

Proost.

Have one oon me.

jpe

[Steven Schweda]

Or, do a quick Google search for something like

vms OR openvms queue entry number

and read any of the similar discussions in
comp.os.vms which date back to 1995, and all
say the same things.

[Robert_Boyd]

What puzzles me is that if the numbers are being read from the user in DCL scripts, the input cannot be limited to 3 characters -- DCL doesn't have a fixed width field read. The problem must be with using F$EXTRACT or F$FAO and thinking that there must only be 1-3 digits. Is this 3 digit limit imposed as some sort of validation of the number? It would be better to use F$GETQUI to validate an entry number if that is the case.

What I fail to comprehend is what value it would provide to program in DCL this way? This inevitably takes more work than just working with whatever length number they type in.

I've always found it better to try to code in DCL to make the scripts as generalized as possible with as few assumptions as possible regarding lengths of string fields and such.

Robert

[Robert Atkinson]

Marc, I think it's important to correct your statement :-

"If you make sure there is no pending or holding queue entry above 1000 and if you then reboot the system then it will again count from 1 till 1000."

This is not actually true (I've tried it in the past).

The only way to reset the numbers back down, as already pointed out, is to initialise the queue database and recreate the queues.

If anyone does find a 'backdoor' method, BTW, I'd love to get rid of our 7-digit entry numbers!

Rob.

[Uwe Zessin]

Hm, unless my memory is corruped, I'd say that _very_ high entry numbers are usually the result of using multiple queue managers.

[Robert Atkinson]

No - it's down to an idiot developer sending 5 entries a second to the queue!

Got quite high before we managed to spot it.

[Marc Van den Broeck]

Robert,

it does work for me, several times.
My cluster is running OpenVMS V7.2-1 and I used it several times to get rid of the high numbers.

But make sure no print or batch entry, even failed print entries with a number higher than 1000 may exist!

Rgds
Marc

[Robert Atkinson]

We're Autogen'ing this weekend Marc, so I'll recheck and send the group the findings.

Rob.

[Wim Van den Wyngaert]

Just did some testing.

After 9999 it jumps to 1000000.

I deleted the queue and rebooted. Started again at 1. As Marc said.

Wim

[Robert Atkinson]

Although the system resets back to 1, you should find that it will not stop at 9999, but will continue back up to 1000000, because the max number has been altered in the database.

Can you try sending a few thousand jobs ($ SUBMIT SYSLOGIN.LOGIN.COM) and see what the entry numbers go up to?

Thanks, Rob.

[Wim Van den Wyngaert]

Test done (testers : don't forget to do diag 7 after to reduce the size of the queue db).

Result : it jumped again. So the reset is done well.

Wim

[Marc Van den Broeck]

Wim,

but while doing that, delete some submitted entries below 1000 BEFORE you reach 1000. If you dont do that, the queue manager has no 'free' job number and will extend the max again.

Rgds
Marc

[Robert Atkinson]

Wilm, from your testing, are you saying the entry numbers went higher than 9999?

Can you also confirm Marc's point - did you allow the entries to complete/run, so that there were only a small amount in the queue at any point in time?

Rob.

[Wim Van den Wyngaert]

Yes they jump from 9999 to 1000000.

Marc : I removed entries while testing. It fills the holes and continues. Just like the first time. So, the reset works fine.

Wim

[Wim Van den Wyngaert]

BTW : the reset is not done by diag 7 (or other diag numbers).

Wim

[Robert Atkinson]

> So, the reset works fine.

Wim, you keep confusing me :-)

Surely you mean the reset does not work. The entry numbers should get to 9999 and then if there are any free slots, should go back to 1?

Rob.