sommar@enea.UUCP (Erland Sommarskog) (10/29/87)
Although many people have posted suggestions for Ernie Perkins to
solve his problem, I submit yet another one here. Somehow I feel
that very few of them relly solverd the problems. As I read his
message he wanted to do was the following:
1) Run job and give it an upper limit.
2) When the job is ready, clean up.
Many articles failed to address the latter problem, and particular,
that 2) should be invoked automaticlly. RUN/TIME_LIMIT or setting
UAF parameters, requiers manual activation of 2).
I didn't really gather if the clean-up only was to be done if the
job ran too long, but it doesn't matter. Below I assume that this
is the case.
The keyword for my proposal is the DCL command SYNCRONIZE. I have
never tried it, but as I understand it, it must do the trick.
Following sketch of command file should be used to start the job:
(It is NOT tested. Some qualifier names be wrong as well as syntax.)
$ jobname := ! Some relatively unique string. Use e.g. current time to
! to construct it.
$ OPEN batch1 RUNJOB.COM
$ WRITE batch1 ! Preludes like SET DEF etc
$ WRITE batch1 "$ CREATE ''jobname'.RUNNING"
$ WRITE batch1 ! Run program
$ WRITE batch1 "$ DELETE/NOLOG/NOCONFIRM ''jobname'.RUNNING;"
$ CLOSE batch1
$ OPEN batch2 CHECKJOB.COM
$ WRITE batch2 ! SET DEF etc
$ WRITE batch2 "$ SYNCHRONIZE ''jobname'"
$ WRITE batch2 "$ IF f$search(jobname + "".RUNNING"") .eqs. """" then exit"
$ WRITE batch2 ! Clean up
$ CLOSE batch2
$ SUBMIT/QUEUE=JOBQUE/CPULIMIT=whatever/JOBNAME='jobname' RUNJOB
$ SUBMIT/QUEUE=CONTROL CHECKJOB.COM
Note that CPU limits etc could be defined for the job queue as well.
The alternative that's have been suggested is to spawn a subprocess
and let the main process monitor it. The advantage is here that we let
VMS do the monitoring for us. We save some, thought very little, load.
The drawback is that we use one more batch entry. If we have nasty
users they may place irrelavnt jobs in the control queue, blocking
CHECKJOB.
--
Erland Sommarskog
ENEA Data, Stockholm
sommar@enea.UUCP
It could have been worse; it could have been Pepsi.