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

[Charles Holley_1]

What is the syntax to that accompanies the submit command to have a job run once a week? I know how to do it on a daily basis, or hourly, but not how to limit it to once a week.

[labadie_1]

Hello

At the beginning of the procedure, a
$ subm 'f$env("procedure")/after="+7-0"/queue=xxx/...

will do it

[Hoff]

So you're familiar with queuing on a daily basis? Ok. The weekly sequence is basically the same SUBMIT /AFTER sequence.

SUBMIT /AFTER=date or a delta or combination time or such. (If you're not familiar with absolute, delta or combination times, take a look at the help library text for time. There's usually a top-level time topic in the system help library, though IIRC the topic name has changed a few times over versions.)

The "sneaky" approach is /AFTER=tomorrow or /AFTER="tomorrow+02:00" and have the stuff run daily, and do a test for the weekday. I use this when I have a few jobs, and I let it run nightly. If the batch job doesn't do anything, it requeues and exits.

Here's some related introductory text:

http://64.223.189.234/node/97

there are other examples around, run a few Google searches for this topic.

Calculating the day of the week is a little bit of DCL-level math; there's no /AFTER=SUNDAY mechanism. (Which might be a nice enhancement, but...) I'm guessing this area may be the source of confusion. And here, the primary lexical function here is f$cvtime. It has most of what you need for the text weekday and numerics, etc.

[John Gillings]

A trick I use to simplify daily or weekly processing is to have a job that runs at the same time every day, usually 1am or 2am. Have it resubmit itself:

$ SUBMIT/AFTER="TOMORROW+01:00" 'self'

Have this job search for and execute procedures based on their name. So, have a directory called [REGULAR_JOBS]. Anything to be run daily is called DAILY_name, for example

DAILY_HOUSEKEEPING.COM
DAILY_DISK_CHECK.COM

Execute them as:

$ dailyloop: f=F$SEARCH("[REGULAR_JOBS]DAILY_*.COM")
$ IF f.NES.""
$ THEN
$ @'f'
$ GOTO dailyloop
$ ENDIF

For weekly jobs, use the day name in the filename, WEEKLY_day_name. For example

WEEKLY_SUNDAY_OPCOM_ROLLOVER.COM
WEEKLY_MONDAY_START_OF_WEEK_REPORT.COM
WEEKLY_SATURDAY_LOGOFF_USERS.COM

$ day=F$CVTIME(,"ABSOLUTE","WEEKDAY")
$ weeklyloop: f=F$SEARCH("[REGULAR_JOBS]WEEKLY_''day'_*.COM")
$ IF f.NES.""
$ THEN
$ @'f'
$ GOTO weeklyloop
$ ENDIF

It's very easy to enable, disable or reschedule jobs just by manipulating the filenames. It's also obvious when they run just by looking at a directory listing.

Another trick for more complex processing is to run the procedure daily, but use the day name as a selector. For example, suppose we want something to run on Monday, Wednesday and Friday. Set it as a DAILY_ procedure as above, but in the procedure itself use:

$ day=F$CVTIME(,"ABSOLUTE","WEEKDAY")
$ GOTO do_'day'
$
$ do_Sunday:
$ do_Tuesday:
$ do_Thursday:
$ do_Saturday:
$ ! do nothing
$ EXIT
$
$ do_Monday:
$ do_Wednesday:
$ do_Friday:
$ ! processing here
$ EXIT

[John Gillings]

oh, and a small improvement to Gerard's suggestion:

>$ subm 'f$env("procedure")/after="+7-0"/queue=xxx/...

Since F$ENVIRONMENT("PROCEDURE") includes the version number, this won't pick up a new version of the file.
Instead use:

F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))

to request the latest version.

[James Cordill]

Charles, All the suggestions above are great, also check out the "kronos" job scheduler on the freeware disk or search "vms kronos" should find it. It can schedule periodic jobs on almost any schedule and they will survive reboots as well. -Jim

[labadie_1]

John

Thanks for the tip.

I think there is still a problem anyway: after a modif in the com file, your method will need 2 resubmits to use the new file, while mine will never use the new com file (or eventually fail will the well-known "error opening primary input file sys$input"...) if the file is purged.

But while some procedures can be released twice without harm, some can't.

So after a modif in a .com file, we are still left with the 2 options:
1) delete/entry, followed by another submit of the new com file
2) copy/overlay my.com; my.com;-1

The option 2 has my preference, as I am sure not the forget/modify some parameter of the job (queue name, job name, log name, parameter P1 to P8, cputime...)

[Anton Walter]

If the procedure gets changed, then on the next execution the old procedure will be executed and the changed procedure will be executed for the first time on the next plus one execution.

This can be avoided with the following construction:

$ IF P1.EQS."1" THEN $GOTO START
$ @name-of-procedure.com "1"
$ EXIT
$START:

at the beginning of the procedure

[labadie_1]

Anton

Nice trick !

Thanks

[Jan van den Ende]

@Gerard Labadie (and others)

>>>
But while some procedures can be released twice without harm, some can't.

So after a modif in a .com file, we are still left with the 2 options:
1) delete/entry, followed by another submit of the new com file
2) copy/overlay my.com; my.com;-1
<<<

We usually use option 3):

Begin the procedure with

$ IF f$environment("procedure") .nes. f$parse(";0",f$environment("procedure"))
$ then
$ --execute resubmit ;0 version for NOW --
$ exit
$ endif


As for the original question: in 2004 I posted this to DCL.OPENVMS.ORG

http://dcl.openvms.org/stories.php?story=04/10/15/8590853

Instructions are in the procedure. It does exatly this, if given parameter "Sunday"


hth

Proost.

Have one on me.

jpe