To resubmit the same batch job at every 15 minutes

[Jorge Cocomess]

Hi,

I have this VMS batch job that I would like to resubmit it self every 15 minutes. Would someone help with the DCL command to do this task?

Thank you in advance.

J

[John Abbott_2]

Hi, how about

$ SUBMIT/AFTER="+00:15"

Be careful where you place the code, at the beginning if you want it to run 15m from when the current routines starts or submit at the end if you want it 15m when the current job finishes.

John.

[Ian Miller.]

$ SUBMIT/AFTER="+00:15" 'F$ENVIRONMENT("PROCEDURE")'

will submit the current procedure (note - it will submit exactly the same file version) 15 minutes from when this command is executed. Note that after a while you can get some drift i.e. if it started out running at 12:15, 12:30, 12:45 etc then it can end up running at 12:16, 12:31 and so on. If you need more precise scheduling there are commercial and freeware packages available for job scheduling.

[John Abbott_2 · Accepted solution]

If you're really worried about it, you can minimize time drift by getting the jobs login time and adding 15 minutes, example;

$ LT = F$GETJPI("","LOGINTIM")
$ NEXT = F$CVTIME("''LT'+00-00:15",ABSOLUTE")

$ SUBMIT/AFTER="''NEXT'"

Note that the submission time is to the minute in the next field.

Alternatively, you could always $ WAIT 00:15 and loop back ?

Kind Regards,
John.

[Heinz W Genhart]

Hi Jorge

I atached a small framework for a self resubmitting Batch Job.

If you have questions about it, just post another message

I hope that helps

Regards

Heinz

[Aaron Sakovich]

I really, really, _really_ like Kronos. It's a free job scheduler that runs, by default, every 15 minutes. It's got a simple set of rules (e.g., "At 07:15 On Thursday NoHoliday command_file") that you put in a Kronos.Dat file and it then handles the repetitive scheduling of jobs. If you ever tweak the data file, it will automatically update the schedule the next time it runs.

You can get it on the Freeware v4 CD.

http://h71000.www7.hp.com/freeware/freeware40/kronos/

Also, check out http://dcl.openvms.org/ for several scripts that will automatically resubmit any given command procedure, with no additional code required in your command file. Just search for "resubmit" -- I recall there are at least a couple out there you could use.

Aaron

[Allan Bowman]

Hi Jorge,
I think there are 3 possible ways to define your "every 15 minutes". You can resubmit at the beginning of a procedure, or at the end to run in another 15 minutes. The problem with using it at the beginning is that if the procedure runs for more than 15 minutes you will end up with multiple versions running. The problem with the end of the procedure is that you are now running every 15 minutes plus the time to run the procedure. The 3rd method would be to look at the current minute of the hour at the end of the procedure - if it is less than 15, resubmit to run at the current hour plus 15 minutes (and similar logic for running at :30, :45, and :00). This would give runs on the exact quarter hours but would skip to the next one if the current run lasted more than 15 minutes.

Allan in Atlanta

[Jan van den Ende]

Jorge,

the one issue with submitting at the end of the procedure is, that you must (be able to) make VERY sure that the procedure will ALWAYS get there!
And that can be harder than it may seem!
For us, it was the reason to change all procedures to do the re-submit as the first activity.
The issue pointed out by Allan about the previous run not yet ended: if that is a problem, then some extra checking is added directly after the resubmit, and if the previous run has not yet ended, then simply this run exits.

Just my EUR 0.02

Proost.

Have one on me.

jpe

[Dale A. Marcy]

I second Jan's remarks about putting the submit at the start of the procedure. Especially with jobs that re-submit themselves frequently. If an error occurrs, the job disappears and nobody realizes it for a long period of time. I have combined some of the earlier suggestions. We have a job that runs at midnight and submits all jobs based on rules for the following day. For repetitive jobs like the one you describe, I have our nightly job submit the first run of the day and then it re-submits itself each run until it exceeds the end of the day. This way, I know if something happens to the job during one days run, it will automatically be started the next day. We make daily checks on our nightly submit job to ensure it is in the queue to run.

[Aaron Sakovich]

These synchronization issues are why it's good to use an external program (Kronos, Resubmit.com) to modularize the process. Your program does what it's supposed to do, the resubmission tool does what it's good at. Write (or download) it once and forget it.

Trying to glom resubmission code into a program that already has a task to accomplish can be quite problematic, as witnessed by the above comments. When you start getting into multiple programs with different tasks all trying to resubmit themselves, you quickly see the beauty of having that code in a separate program.

I long ago traded out custom code in each program to resubmit itself, to a separate Resubmit.com, and then ultimately to Kronos. I'd discovered after many years (and many wheels) the adage about not reinventing the wheel...