how to schedule command procedure to run daily

[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