Start an execution queue for only one job ???

[ChaimBu]

Many times we need to execute a particular job during the normal working hours of the day, during which time all the execution queues are STPPED.

Is there an elegant method to start the execution queue for only this one particular job, and after the completion of that job the queue will stop itself?

Currently we start the queue and then immediately use stop/next. However, this in reality could allow a second job to start executing if the stop/next command is not issued fast enough and the first job is very short.

Thanks,

Chaim

[Ian Miller.]

You have a execution queue which is not normally used into which this job could be moved. This one queue could be running when the others are stopped and also could be protected to prevent use by users who submit jobs to the normal queues.

[Karl Rohwedder]

You may use a special queue with access control so that only this job may be submiited, if feasable.
Or other jobs are submitted with /HOLD and a 'control'-job release them for the night.
Or, if privileges allow, the running job does the STOP/NEXT at the beginning.


regards kalle

[ChaimBu]

Thanks for the replies! However, I specifically requested an elegant solution.

If Guy Peleg is monitoring this forum, perhaps he can introduce a qualifier to the START command which would default to ONE but allow a number, telling the queue manager to keep the queue started only for the explicitly stated number of jobs.

Something like:

START/DURATION=2 ....

This would mean, start the queue and allow it to remain started from now until two jobs have completed.

Thanks,

Chaim

[Bojan Nemec]

Chaim,

You can also run the job without a batch queue. This depends on the privileges of the submiter (needs DETACH privilege). You can do this with:

$ RUN/DETACHED SYS$SYSTEM:LOGINOUT.EXE -
/INPUT= -
/OUTPUT=

For more see: $ HELP RUN PROCESS

Some problems you can encounter:
The process mode (F$MODE) is not BATCH but OTHER.
You can not pass parameters. (But you can write a temporary command procedure which will pass the parameters)
You can not use queue synchronization (SYNCHRONIZE).
You can not submit the job as a different user (SUBMIT/USER).

Remember that the program to run is allways SYS$SYSTEM:LOGINOUT.EXE. This gives you the DCL.

Bojan

[Jan van den Ende]

Chaim,

really, the most elegant solution _IS_ a dedicated queue! And if somehow there is some difficulty in SUBMITting /QUEUE=.. (eg, when the submit is by a call to $JBCSNDQUE from within an image that can not easily be changed) the just DEFINE SYS$BATCH for the submitting image or process.

just my opinion though...
Proost.

Have one on me.

jpe

[John Gillings]

Chiam,

I'm trying to work out your objective here. Is it to start a specific job, or to "drip feed" jobs from a queue on demand?

If it's a specific job holding, then SET ENTRY/RELEASE will allow it to start. If it's on a stopped queue then SET ENTRY/REQUEUE=some-running-queue can move it to a running queue. All you need is one "emergency run" queue to which these jobs can be submitted. It could be protected to prevent mere-mortals from submitting jobs to it.

If it's the next job on a queue, you could use F$GETQUI to find the entry number, then SET ENTRY/REQUEUE to get it running.

I can't see how this is any less elegant than building in yet another qualifier on SET QUEUE. You can use /REQUEUE today and for the last 2 decades (~ VMS V2), but even if your proposal is accepted, and work on the new qualifier starts tomorrow, you won't see it for at least a year, if not longer.

Consider, if you want your "start queue for 1 (or N) jobs" semantics to work, you need to first arrange for your target job(s) to be at the head of the queue. With requeue you have absolute control over which jobs start, one command to do it, and all it costs you is one extra queue.

[Thomas Ritter]

We have over 300 batch queues and run some thousands of jobs per day. We have all sorts of requirements where jobs may need to be manipulated. VMS is so rich in DCL features that we meet our operational needs with command procedures which are typically executed from a MENU. Dare I suggest you explore DCL and the rich set of lexical function provided by VMS ?

[ChaimBu]

Hi Guys !!

Thanks for all the replies!

In reality, I really do NOT have a "problem".

Our installation does NOT allow any large batch jobs to run before 16:00 in the afternoon. The batch queues for the BIG jobs are stopped on system reboot (a reboot is done every morning at 6:30) and automatically started at 16:00. All BIG jobs are submitted to generic queues which are also stopped and automatically started at 16:00 and which feed the execution queues.

On rare occasions a BIG job needs to be run during the day. Theoretically, the execution queue at this point SHOULD be empty. So theoretically I should be able to enter a set entry/requeu=execution-que, set ent/rel, start/que execution-queue and stop/que/next execution-que and honky dorey! However, if by some chance AFTER I started the execution-que ANOTHER job somehow was placed on the execution-que, and the BIG job ran faster than than I was able to issue the stop/que/next command, then this second job WOULD start to execute as well. This unexpected situation is what I am trying to eliminate using a manner which is elegant and automatic and which does NOT rely on my personal reflexes.

So far NONE of the solutions that I have seen so far are very elegant, and those that are elegant do NOT really solve the "problem" as I have described it.

Hope I have clarified myself!

Thanks,

Chaim

[Wim Van den Wyngaert]

Chaim,

The execution queue can be a special queue that is started at boot time (e.g. with autostart enabled).

If needed, protect it so that nobody can use it except system managers.

Then all you need to do is set entry/reque and the job will start on the exec queue.

Simple. Isn't it.

Where I see problems is when the job itself starts series of other jobs in the same stopped queue or when a monitor is running that expects to see the job terminated in the original queue.

Wim

[Nigel Wright_1]

Another approach is to place a header in your big jobs you run. The header will check for the existence of a P1 parameter, if this is say 'stop_next', then issue the command stop/next/queue='queue_name'.

The P1 can be given under the set entry/par qualifier.

Hope this helps.

Nigel.

[Nigel Wright_1]

Just had another idea.

Create a dcl file (run interactively) that firstly creates a batch queue, places acls on it so that only the person running the dcl file can do anything with it, inquire the entry to move to the queue, run the entry on the queue. Check entry progress, when completed, stop and delete the queue.

[Ian Miller.]

"a reboot is done every morning at 6:30"

I'm wondering why?

[John Travell]

Nobody seems to have mentioned setting a queue to /job_limit=1
This would unconditionally prevent a second job from starting until the first had completed, so that you only have to allow for abnormal termination of the approved job.

[ChaimBu]

We do a reboot as this is the policy of the site. For nightly backups many of the applications are interrupted and databases are closed etc. Rebooting assures that the systems are all up and running properly for the us.

Of course the job_limit is set to 1. I thought that this was obvious! My "problem" us more of a "race condition" whether the job will execute and complete BEFORE the operator has the opportunity to stop/next the queue.

[John Travell]

Then why not make a batchshell procedure that does something like
$ stop/que/next
$ get batch job params
$ check params are valid
$ run real task specified in params
$ exit

then do
$ submit /que=onejobonly batchshell /param='real job details'
$ sho que onejobonly
(to verify that the only job in it is the one you want to run, delete any unwanted jobs)
$ start/que onejobonly

[ChaimBu]

Thanks all !!!

I believe that the subject has been discussed quite extensively, and although I really didn' receive any suggestions that are either elegant and/or feasible, I see no reason to kep this thread open.

Thanks a mill !!!!!!!!

Chaim

[ChaimBu]

Closing as I stated in my last reply/

Thanjs,

Chaim

[Jan Nuyt]

At end-of-procedure:
- calculate time between "now" and the moment that next job is allowed to start.
- $ WAIT

[Jim_McKinney]

> Is there an elegant method to start the execution queue for only this one particular job, and after the completion of that job the queue will stop itself?


You might explore the use of the /CHARACTERISTIC qualifier on both the batch queue and entries submitted to it. See HELP SET ENTRY and HELP SET QUEUE.

The short of it is to designate the queue to possess a characteristic that no jobs possess. If you are not currently making use of /CHARACTERISTIC then you might just choose a value of "1". Issue a "SET QUEUE/CHAR=1 {queuename}" and no jobs will execute in this queue unless they posses the "1" characteristic. When you wish a specific job, and only that job, to execute you need only "SET ENTRY/CHAR=1 {entry}" (all other jobs will continue to wait). You can at any time "SET QUEUE/NOCHAR{queuename}" to release all pending jobs.

[Phil.Howell]

I think the /CHARACTERISTCS method the most elegant!
Phil

[Marc Van den Broeck]

Phil,

be careful afaik all jobs without a characteristic will start on the queue. Only a job with a characteristic that doesnt match the characteristic on the queue will stay pending.
So, 'normal' submitted jobs will just start if you start the queue.

Rgds
Marc

[Jim_McKinney]

> So, 'normal' submitted jobs will just start if you start the queue.

Marc is correct (it's been a long time since I'd used this feature and mis-remmebered, sorry).

Anyway, "/CHARACTERISTIC" can still be used. All jobs could be SUBMITed with a "/CHARACTERISTIC" and that "/CHARACTERISTIC" would be removed from each job (via SET ENTRY) as their execution was desired. (All jobs could be released by temporarily assigning the "/CHARACTERISTIC" to the batch queue.