1748062 Members
5761 Online
108758 Solutions
New Discussion юеВ

Re: Scheduler

 
SOLVED
Go to solution
MPIvan
Occasional Advisor

Scheduler

Hi all,

Im trying to learn this new OpenVMS. Im very new, and it is my first time.
I have start this conversation a long time ago. Now im in deep of this problem and i would like to solve it.

I have one procedure that have to be execute every day. Is there any kind of scheduler for OpenVMS system?
The procedure that is i execute like this:
"submit /noprint <name_procedure>"
the procedure is .com extension.

so this would be like: "submit /noprint backup.com"
when i execute this there is a log file crated and i want this log file to be send on e-mail when its finish. How can i do this ?

 

Im running OpenVMS V7.3-2  

19 REPLIES 19
abrsvc
Respected Contributor
Solution

Re: Scheduler

The task you request is completed using DCL code within the procedure.  Essentially you re-submit the same job with a scheduled runtime as shown below.  Place this code at the beginning of the procedure and it will submit itself for execution at 1/2 hour after midnight.

 

 

$ SUBMIT -

/restart -

/AFTER="TOM+00:30:00" -

/LOG_FILE=DAY.LOG -

DAY.COM

 

 

As far as sending an Email, place the following line within the procedure after the work is completed and before the procedure exits.

 

 

$ mail -

/sub="message log_file.log

smtp%"user@location.com"

 

 

Hope this helps,

Dan

MPIvan
Occasional Advisor

Re: Scheduler

Thanks Dan,

 

Thanks for reply / help.

 

So lets say that im having procedure where i will create a file and says "hello ivan"

 

If i want every day to make a file saying Hello Ivan, i will do this:

 

$ SUBMIT -
/restart -
/AFTER="TOM+13:30:00" -
/LOG_FILE=DAY.LOG -
DAY.COM

$ OPEN/WRITE test HelloTest.dat
$ WRITE OUTPUT_FILE "Hello Ivan"
$ CLOSE OUTPUT_FILE

$ mail -
/sub="message log_file.log
smtp%"user@location.com"

 and all this will be in the file called "TestScheduler"

 

or should i have make DAY.com be the file that will contain the 

$ OPEN/WRITE test HelloTest.dat
$ WRITE OUTPUT_FILE "Hello Ivan"
$ CLOSE OUTPUT_FILE

 :D OMG im soo noob im loost here i have excellent experience in Linux but with this im NOOB :D

????

 

Steven Schweda
Honored Contributor

Re: Scheduler

 
John Gillings
Honored Contributor

Re: Scheduler

Re: Steve's post

 

>>but the last thing it does is re-sumbit itself:

 

I recommend that a recurring batch job resubmit itself as the FIRST step, rather than the last, that way the job will always be resubmitted regardless of what happens in the body of the procedure. There are valid arguments both ways.

 

A job resubmitting itself is a very common requirement. There are many pitfalls involved in losing the thread, creating multiple threads, version changes (take note of Steve's F$PARSE(";")), handling qualifiers and parameters, running the job ad-hoc, etc... Unfortunately DCL doesn't have any generic tools for easily managing recurring jobs.

 

Mailing a jobs own log file can be tricky, as you're still executing (and thus potentially still writing the log file). One method is to jacket your procedure:

 

$ @REAL_PROCEDURE/OUT=logfile
$ MAIL/SUBJECT="log file" logfile distribution-list

 

You can capture a copy of the current live log file which can be mailed:

 

$   tmp=F$PARSE(F$UNIQUE(),"SYS$SCRATCH:.TMP;")
$   mylog=F$PARSE(F$GETQUI("DISPLAY_ENTRY","LOG_SPECIFICATION",,"THIS_JOB"),"SYS$LOGIN:.LOG;",-
                  F$GETQUI("DISPLAY_ENTRY",         "JOB_NAME",,"THIS_JOB"))
$   TYPE/OUTPUT='tmp' 'mylog'
$   MAIL/SUBJECT="Log file to date" 'tmp' distribution list
$   IF F$SEARCH(tmp).NES."" THEN DELETEX 'tmp'

 

Note that LOG_SPECIFICATION only returns a non-null value if there was a log file explicitly named in the SUBMIT command, so the F$PARSE will fill in a default. TYPE is happy to read the contents of a file open for write by another process (or self), but MAIL isn't. That's why we need the temporary file.

 

Note that there are further assumptions here - for example, if there are two instances of the same job running, this will capture the log file of the most recent job, which is not necessarily the current job. If this is an issue, you'll need to back translate the file name from SYS$OUTPUT, which is not something you can do directly in DCL (I can post a program to do it if required).

A crucible of informative mistakes
Steven Schweda
Honored Contributor

Re: Scheduler

 
Dennis Handly
Acclaimed Contributor

Re: Scheduler

>I recommend that a recurring batch job resubmit itself as the FIRST step,

 

Good point.  This would be equivalent to UNIX's cron(1m).

Of course with at(1), you can resubmit at first or last steps.

MPIvan
Occasional Advisor

Re: Scheduler

Thanks to all for replying !

 

I realy need this. 

 

I see that you all start conversation about resubmit the job. If the system goes down or restart itself the job will start. I dont want to do this. I just want typical scheduler job. Every day in 08:00 PM to start this procedure and when its finish to send me the log file. Every day i start this procedure like this: "submit /noprint backup" --- where backup is the procedure named "backup.com". Here is what have in backup.com

 

set ver
set noon
rmu /show user
rmu /repa/abm dkb6:[vg]vg.rdb
show time
sql export data file dkb6:[vg]vg.rdb into dkb9:[back]vg.rdr;
show time
purge dkb9:[*....]
back/log/media=comp dkb9:[back]*.* mka500:backup.bck
dismount mka500:
!back/log/over/ignor=inter dkb6:[vg]vg.rdb dkb9:[backi]vg.rdb
@dkb4:[ivan]imptt
purge dkb9:[*....]

 and this is not my. I didnt make this file, but i have to execute every day. So my job for now is to make this file execute every working day in 08:00 PM ( mon-frid), and when its finis to send me tthe mail , the mail can contain the log file that it is created ( becouse when i execute this procedure it create the log file named backup.log in the default directory, im guessing, the log file is created because i executed with submit/noprint ... but i dont know realy :) ). 

Steven Schweda
Honored Contributor

Re: Scheduler

 
John Gillings
Honored Contributor

Re: Scheduler

Steven,

 

>I failed to mention that the _first_ thing my script does is:
>
>      $ SET NOON

 

   Of course. That will deal with errors, unexpected or otherwise in the body of the procedure, but it doesn't help for system crash, power fail, normal shutdown, STOP commands (internal or external), infinite loops, lock conflicts/deadlocks, future edits which bypass the exit path, or any of the other gazillion things that might cause a process to stop, hang or be excessively delayed between the start and your (re)SUBMIT at the end. The longer running the job, the wider the timing window.

 

   Resubmission at the top still has a small timing window where there is no pending job. I like to have a "watchdog" type process which knows which jobs should be scheduled and can alert or resubmit anything missing (and yes, it also watches itself by having backup "deadman" copies of itself waiting to take over). The system startup process just need to make sure the watchdog is running, and everything else cascasdes from there.

 

  In a lot of ways the Unix cron model makes this kind of task a lot easier to manage (but then it has the problem of tracking the job - "did it run?" and "where the &^%&^% did my log file go?") 

A crucible of informative mistakes