batch queue on startup 7.3-2

[sandyt]

I have a problem with the batch queue on an alpha server running openvms 7.3-2. On startup, the computer runs all the jobs in the queue regardless of their scheduled times. Once up, and the jobs have been re-submitted, the queue runs smoothly.

sh sys$batch/full
Batch queue SYS$BATCH, idle, on ALPHA1:: /BASE_PRIORITY=2 /JOB_LIMIT=2 /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S)

Any input appreciated.

[Karl Rohwedder]

Systemclock and holding-times are o.k.?
Is this a new problem?

regards Kalle

[Jan van den Ende]

sandyt,

if the jobs have a /AFTER time specified, and that time has already passed (according to the system time), then this is intended behavior.
Kalle already mentioned the potential of incorrect clock setting.

If no starting time is specified, then they run immediately. In that case, it may well be that the entire environment necessary for the run has not been set up or started.
If the latter is the case, then you COULD start with code to check if the job can already run, and wait or resubmit if not.


hth

Proost.

Have one on me.

jpe

[Robert Gezelter]

sandyt,

I would want to know the actual times displayed for the queue and the system time at startup.

I would suggest an experiment: Do a full listing of all of the jobs in the queue; and then restart the machine.

Then do a display of the queues following the restart.

I have also seen some systems that are setup to re-submit batch jobs on startup. Have the startup processing been checked to ensure that this is not what is being seen?

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

[sandyt]

Thanks for the replies. Perhaps the global system time variables are problematical, but when the system comes up it does have the proper time (it has not remembered daylight savings time for example at least on one occation).

The batch queue has jobs that are supposed to run throughout the day, and even those that are supposed to run every Sunday for example. (they all re-submit themselves by the way).

what is happening at the moment is that all the jobs seem to run on startup regardless of their scheduled times (see attached file). We changed over to the alpha from a vax about a year ago, and have maybe rebooted 3 times since going production.

I will put in a "stop/queue/reset sys$batch" in the startup job to see if that has any effect.

I guess it isn't so critical as we normally only reboot a few times a year, but it is a nuisense.

Regards

[Wim Van den Wyngaert]

May be something in your system startup is releasing the batch jobs ? We remove certain jobs (with reason) but I don't see any reason why one would release jobs, but you never know.

Did you check the operator log file of the system ? May be some unexpected time changes were done.

Do you use a time server ? Which one ?

fwiw

Wim

[Robert Gezelter]

sandyt,

Thank you for posting the results of the queue display.

If you prevent the queue from autostarting, it would be helpful to see a queue display FOLLOWING a reboot (along with a display of the system time stamp at that time).

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

[John Gillings]

Check the time after startup very carefully. There are situations that could cause it to be +/-1 day or even +/-1 year! Obviously if the queue manager thinks the current time is later than a job holding time, it will start the job.

Turn on LOGIN AUDITs to see when the jobs are starting. This will confirm the (subjective) system date and time. If there's a bug (which is very doubtful) the audits will prove a job starting before its start time.

To check for entities that might be releasing jobs, try enabling audits for queue access, or put an AUDIT ACE on the queue.

[sandyt]

Again thanks for all the helpful suggestions. I will put them into practice for the next startup and see.

In regards to your question Wim, I recently put in a NTP time server, but the problem with the queue started before that, so I don't think that it is related.

Thanks again for your time and input.

Regards