how to schedule command procedure to run daily

[Scotty HD]

how to schedule command procedure to run daily

i have one command procedure and need to execute it daily at 1:00.

now i written com procedure in such a way that it schedules itself
again on next day. this way the com procedure recursive schedules
itself to run everyday at 1:00.

there was nothing in SUBMIT command for recursive execute daily.

is there better way ?

Scotty

[Hoff · Accepted solution]

http://labs.hoffmanlabs.com/node/501

[Scotty HD]

hoff>>
is it like this
# only one main scheduler job that run daily.
# this main scheduler job that run daily and schedules all other job like x1, x2, x3 ...
based on their requirement.

the main scheduler task that run daily, how to schedule that!

Scotty

[Scotty HD]

in the link
-->Caturday, err
is it typing mistake ?

Scotty

[Shriniketan Bhagwat]

Scooty,

You should explore using the BATCH facility that comes with VMS.
Basically create a command procedure that contains the commands that you want to run. Then use the below command to submit the procedure.
$ submit/after="tommorow+1:00:00" -
command_procedure_name.com ! resubmit
$!
$! rest of procedure follows...

Regards,
Ketan

[Hoff]

The following is a more direct example than what I had posted:

http://labs.hoffmanlabs.com/node/1476

and I've updated /501 with more links.

I'd definitely look to replace this stuff; the default scheduling in VMS is weak; I know it is very frustrating to work with. This frustration even if all you're accustomed to working with is Vixie cron.

[Jon Pinkley]

Scotty,

Use ITRC's Forums advanced search for SUBMIT in the OpenVMS forum, you will see this is a common question. Look for the link at the top of the page

http://forums.itrc.hp.com/service/james/searchForums.do?searchText=submit&searchCriteria=allwords&searchOptionITRC=true&searchCategoryITRC=OpenVMS&searchIn=entireThread&author=&threadType=0&datePosted=0&sortOption=rank&resultsPerPage=25&x=23&y=8

Here are a few relevant threads:

submit DCL command question

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1237510

Submit com proc to batch que to run once a week?

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1232913

Submit command (What is the command to submit a backup every 7 days from tomorrow onwards at 7am?)

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1098806

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

If you were just wondering if there is any way to automatically repeat the submission at a period interval, the answer is no.

The DCL SUBMIT command is just a DCL interface to the SYS$SNDJBC system service. SYS$SNDJBC allows batch job to be submitted at a specific ABSOLUTE time, and there isn't any "REPEAT" capability built in.

So your options are to have each command procedure compute the next run time, and then resubmit itself, or to have something running that will do the scheduling based on a list of jobs (as Hoff suggested).

That "something" could be a batch job that resubmits itself every day, or a detached process running a scheduler like cron or kronos, etc. cron or kronos are generally started in system startup and just run "all the time", but spend the vast majority of their time sleeping (HIB).

OpenVMS Job Scheduler - Recomendations

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1064251

A quick google search found this list of third party schedulers for OpenVMS

http://unix.derkeiler.com/Newsgroups/comp.os.vms/2008-05/msg00993.html

Good luck,

Jon

[The Brit]

Hi Scotty,
The method I use is as follows. Right at the beginning of your script, add the lines;

$ RSub_Time = f$cvtime("TOMORROW+08:00","ABSOLUTE",)
$!
$ Submit -
/queue = -
/After = "''RSub_Time'" -
/Log = LOGS_SCRATCH: -
/NoPrint -
/User = -



it works for me.

Dave

[Hein van den Heuvel]

Free advice...

Once you have such procedure running, you may find the need to change it.

Probably you already decide to parse the procedure name from F$GETQUI or F$ENVIRONMENT to select the highest versioned number, not the current version for the next run.

But what if you want to change the already submitted job? You can NOT just edit it nd put a next version, because the submit is by file-id, not by name.

So you have to DELETE/ENTRY andre-submit, or use:

$ COPY/OVER improved-job.com job.com

That will replace the contents, for a file, keeping the file-id of the target.

Hein

[Scotty HD]

Hoff>>
thanks for programs. i will try using them today.

Shriniketan>> , The Brit>>
this is what i doing now.
but if for some reason if the command procedure does not run
(quota problem or whatever) on monday then it wont run on tuesday.
this create problems.

Jon Pinkley>>
#If you were just wondering if there is any way to automatically repeat
#the submission at a period interval, the answer is no.
thanks. i wanted to hear this answer. i was looking for repeat capability.

Hein>>
#But what if you want to change the already submitted job? You can NOT
## just edit nd put a next version, because the submit is by file-id,
# not by name.
thanks much. you answered question that i was about to post today.
every time i schedule batch job. i then modify the command procedure.
but every time my modification dont appear.
as you said, it always takes old file because it remember file-id not name
i will look at the lexical you given to see how i select always latest
command procedure to run. now i know what the mystery was.
#Free advice...
no. its magic advice.
this should save a lot of manual work everytime i change my command procedure.

Scotty

[The Brit]

That is why is is submitted as the first step in the job. Providing that the batch job actually starts, then it will always submit for tomorrow.

The only things which will normally stop the job from starting are;

1. The submitted com file (version) is gone or not found.
2. The Log file cannot be created (bad location or insufficient space.)

Dave.

[Mike Kier]

The other trick is to use two command files.

The first just resubmits itself and then invokes the one to do the work, which is likely the one you need to change periodically.

By decoupling into a second procedure, you can change it as often as you need and it will be picked up by the next scheduled run, or you can even stub it out with a dummy procedure for times when you don't want it to run but don't want to break the rescheduling.

[Scotty HD]

The Brit>>
one problem that happened here was system reboot on monday and the
queue remains in stopped state. my script does not run on monday.
i later start the queue. but then the script has not run on monday and hence
would not have scheduled itself to run on tuesday.
manual work required here to schedule my script again.

Mike Kier>>
#By decoupling into a second procedure, you can change it as often
# as you need and it will be picked up by the next scheduled run
this sounds good. even if my script change, the latest version get
scheduled.

Scotty

[Jon Pinkley]

Scotty,

I would have expected the job that was scheduled to run on Monday would have started running immediately when the queue was restarted. In other words, if a job was scheduled to run Monday, May 31, 2010 at 19:00, and the system was rebooted at 31-MAY-2010 18:00, but the queue was not restarted, the job entry would still be in the queue. If the queue was restarted on Tuesday morning at 9:30 AM, I would have expected that entry to start running immediately, unless you took steps to prevent it. If it did run, and scheduled itself to run "TOMORROW+19:00", then the next run would be on Wed, June 2, 2010 at 19:00.

I have no idea how many queues you have, but to avoid the problem of queues being stopped after a system reboot, the normal method is to have the queues started either by something in sys$startup:systartup_vms.com or something it executes.

We have logic in our startup to automatically recreate queues if they are not present. This can be done by always using an initialize/queue in the startup. If the queue already exists, it will not delete the entries that are already in the queue, but it will reset any properties that are specified in the initialize command, for example the /job_limit.

If you want the queues to restart, you can just add /start to the initialize/queue command.

VMS also has autostart queues that will start when autostart queues are enabled.

However, even this isn't enough to handle every possible situation. For example, what it the system was shutdown for an extended period of time, and the date changed during the shutdown? Then you are going to have to build more into the command procedures (if they are doing the rescheduling). I don't think that cron is immune to all problems either. For example, what if the system is down when a job was schedule to start. I would expect that job to just be skipped.

The VMS queue tries not to loose entries, but this can lead to problems too. For example, if a system is shutdown prior to a large overnight batch job, and restarted right before the start of the workday. Unless some manual intervention is used, the job will start as soon as the queue is started, and that may not be the wanted behavior.

Often designing command procedure and programs for the exceptional cases that occur infrequently, takes a large part of the programming time.

Jon

[Jon Pinkley]

Scotty,

Generalizing on what Dave (The Brit) wrote:

A batch process can't be created if it cannot open its input or output files.

Some specific reasons follow (this probably still is not a complete list)

1. can't open input file: submitted file has been deleted, or user has no read access to file (could be because it was renamed to a protected directory).
2. can't open log file: insufficient space (device full, quota exceeded - will not use overdraft), directory not found, directory full and can't be extended due to lack of contiguous space, highest legal version (;32767) of log file already exists, user does not have write access to directory.

Easiest method to determine problem: use $ submit/retain=error ...

Using /retain=error also has the advantage of leaving an indication that there was a problem.

You can also use /retain=always or /retain=until=time ! absolute or delta (from completion)

You can also use /notify to notify via a broadcast message when the job completes.
This will also give a more limited status.
The broadcast is sent to the username that the job is executing under, which is not necessarily the user that submitted the job.
The broadcast is sent with class QUEUE, so to receive the message, the user must be logged in, and the terminal must be set /broadcast and QUEUE broadcast must be enabled.

Here is an example of submitting a job when disk quota has been exceeded on the log device:

$ submit getqui/noprint/log=sys$scratch/que=sigma$batch/retain=err/notify
Job GETQUI (queue SIGMA$BATCH, entry 3007734) started on SIGMA$BATCH
$

Job GETQUI (queue SIGMA$BATCH, entry 3007734) terminated with error status
%RMS-E-CRE, ACP file create failed
$ show entry 3007734/full
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
3007734 GETQUI PINKLEY Retained on error
%RMS-E-CRE, ACP file create failed
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded
On idle batch queue SIGMA$BATCH
Submitted 6-JUN-2010 00:59:24.04 /KEEP /LOG=DSA1200:[USERS.][PINKLEY].LOG; /NOTIFY /NOPRINT /PRIORITY=100 /RETAIN=ERROR
File: _DSA1200:[USERS.PINKLEY]GETQUI.COM;14
Completed 6-JUN-2010 00:59:24.17 on queue SIGMA$BATCH
$

For more information:

$ help submit/retain
$ help submit/notify
$ help set terminal/broadcast
$ help set broadcast
$ help show entry /by_job_status ! for info on show entry /by=retained
$ help show queue/by_job_status
$ help date ! to see how date/time can be specified

Jon

[The Brit]

Hi Scotty,
You should still be OK, even if the system boots. If the queue is stopped when the system boots then the job will wait until you start the queue and then execute normally, submitting for Tuesday (at normal time).
If you dont want the job to execute on Monday, then just add the line,

$ If (f$cvtime("Today",,"Weekday") .eqs. "Monday") then Exit

RIGHT AFTER THE SUBMISSION COMMAND.

This will cause the job to submit for normal time on Tuesday, and then exit.

Dave.

[abrsvc]

RE: The Brit>>
one problem that happened here was system reboot on monday and the
queue remains in stopped state. my script does not run on monday.
i later start the queue. but then the script has not run on monday and hence
would not have scheduled itself to run on tuesday.
manual work required here to schedule my script again.


=======

What we have done to cover the instance described above is to use the 2 procedure method and supply the "day" as a parameter to the "working" procedure. In this fashion you can test to be sure that the running procedure is for the correct day. This will address the case where the machine goes down for a while and the batch jobs can get out of synch.

Dan

[Scotty HD]

thanks all for reply.

Jon Pinkley>> , The Brit>>
i check my script again. from what you explain the job should start when
the queue get started again.

Jon Pinkley>>
/retain=error is the change i did already. this is a good option.
thanks for the pointers.

abrsvc>>
i will also plan for two command procedures. i will keep you point in mind.

Scotty

[Scotty HD]

thanks all for reply
will do changes that has been recommended.

Scotty