How to detect duplicate auto-resubmiting batch job - VMS

This is a discussion on How to detect duplicate auto-resubmiting batch job - VMS ; vancouvercancun@yahoo.ca wrote in news:1187122509.791422.293350 @l22g2000prc.googlegroups.com: > Hi everybody > I have a auto-resubmiting daily disk cleaning job. It is submitted at > startup and should be resubmitting itself after running every day at > 8h00. Yesterday, I noticed I now ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

Thread: How to detect duplicate auto-resubmiting batch job

  1. Re: How to detect duplicate auto-resubmiting batch job

    vancouvercancun@yahoo.ca wrote in news:1187122509.791422.293350
    @l22g2000prc.googlegroups.com:

    > Hi everybody
    > I have a auto-resubmiting daily disk cleaning job. It is submitted at
    > startup and should be resubmitting itself after running every day at
    > 8h00. Yesterday, I noticed I now have 3 entries for the same job, all
    > waiting to execute at the same time. Notwithstanding the fact that
    > some startup job is submitting the batch more than once(I will need to
    > find it!), I need to add code to my DCL procedure to verify that only
    > one job is present.
    >
    > What is the usual way to detect that there is only one instance/job/
    > batch of the procedure running daily ? What code can I use in DCL to
    > verify that I have only one version of the batch job present in the
    > queue ? Can you provide examples ?
    >
    > Here is a part of my cleaning.com procedure:
    >
    > $ datelog = f$cvtime("tomorrow","comparison","date")
    > $ submit /queue=sys$batch /noprinter /nonotify /restart /log=my
    > $log:cleaning-'datelog'.log -
    > /after="tomorrow+08:" cleaning.com
    > $ delete my$log:*.log;*/cre/before=today-30-0
    > $ ...
    >
    > Yesterday, I had 3 entries waiting to execute at 8h00. I would like
    > entries 2 and 3 to kill themselves if there is already a same job
    > present in the queue. Notice all 3 will be begin executing in the same
    > split second.
    > Suggestions ? Examples ? Links to code ?
    > TIA
    > Van
    >


    It's interesting to see the variety of solutions.

    Since you only want the job to run once a day, it would seem that the job
    should immediately create a file unique for that day, e.g. cleaning.2007-
    08-24;32767, in a directory which only grants write access to the
    username running this job. If the creation of the file fails and it is
    then found to exist, the current job should be aborted (because another
    job is running or already ran.) If this test is performed before the
    resubmit logic, the queue will be cleaned by attrition.

    The problem I see with using a process naming method is the potential for
    an interactive user setting their own process name to match, as they
    tinker. Similarly, users can create jobs with the same name. If you
    plan to use the F$GETQUI lexical, you'd certainly want to check the
    username and/or the command procedure for the jobs with matching names.

    If you were only concerned with the command procedure running concurrent
    to other instances, the solution there is probably something like a
    clusterwide resource lock, or even an empty file opened with exclusive
    access, and then just looping (with some delay) until it is able to open
    that file.

    Hopefully, the solution you find will serve you well for future
    situations so that you may avoid working on problems that consume many
    hours.

  2. Re: How to detect duplicate auto-resubmiting batch job

    Quote Originally Posted by unix View Post
    Or use *non*-autosubmitting jobs.
    I uses a CRON-like tool called CRON :-)

    It's a DCL routine running as a detached
    process checking a config (text) file each
    even hour and anyware where the is is match
    (on the hour/weekday/day-of-month fields) the
    command (usualy a SUBMIT) on the same line is
    executed.

    Rock-sold. Starts at boot and never dies. :-)

    One odd thing...

    SHOW SYS says "Uptime 584 17:08" but the
    SHOW PROC/ACC on the CRON process says
    "Connect time 584 18:59". So the CRON process
    has been running for aprox 2 hours *more*
    then the currect uptime :-) :-)

    Anyway, I have currently aprox 20 SUBMIT's in
    the CRONTAB.DAT which is scanned each hour.

    Main pros :

    - Easy to "list" all regular batch jobs. Just
    TYPE the text file. No need to run SEARCH over
    all protential COM files...

    - Easy to change (or disable) any batch job. Just
    delete or comment the line in the text file. Or
    change the hour-field or whatever.

    The text file is re-read each cycle, so there is no
    need to re-start anything after an edit.
    Yes - I've used the same VMSCron and it is great - can you post a copy? Thanks.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2