Conference humane::scheduler

1207.0. "jobs run twice although dependency" by UTRTSC::KNOL (isn't every bug a bit wrong) Wed Feb 05 1997 05:07

    strange or expected bahaviour???
    I've set up a test to check the dependency

    test.com       (job198 scheduled to run )
$sh sys /out=t.t
$wait 0:01:00.00
$exit 1


    	test2.com

$search t.t blabla (job 199 scheduled time set before job 198)
$exit

    test3.com

$show proc blabla/out=t.t
$exit 1

    test4.com
$search t.t lta
$sched mod 198/next="+0000 00:05:00.00"
$sched mod 199/next="+0000 00:00:30.00"
$sched mod 200/next="+0000 00:00:30.00"
$sched mod 201/next="+0000 00:00:30.00"
$exit 1
    
    the jobs are in a straight dependency 201 waits for 200 and 200 waits
    for 199 and 199 waits for 198 to complete
    and this is what happens:
    Scheduler job #198 (Name: TEST) Started on node PTGSYS
    Scheduler Job #198 (Name: TEST) Completed on node PTGSYS
    Scheduler job #199 Started on node PTGSYS
    Scheduler Job #199 Completed on node PTGSYS
    Scheduler job #200 Started on node UTURBO
    Scheduler Job #200 Completed on node UTURBO
    Scheduler job #201 Started on node UTURBO
    Scheduler Job #201 Completed on node UTURBO
    Scheduler job #200 Started on node PTGSYS
    Scheduler Job #200 Completed on node PTGSYS
    Scheduler job #201 Started on node PTGSYS
    Scheduler Job #201 Completed on node PTGSYS
    
    
    
    as you can see jobs 200 and 201 ran a second time???  how is that
    possible?
    
    regards jan
    

    what the log screen show is as follows

    job 198 was scheduled is now running
    job 199

    

    If I do understand correctly from the details ;0 it means only job 1
    takes at least a minute, the other can run very fast since it only
    contains a search.
    Jobs which take a few seconds are known in scheduler to produce
    problems, since the timestamps are entered in the job char's when the
    scheduler enginer processes the requests. The order of processing can
    be out-of-band. See the release notes for more details.
    
    The only workaround is to include e.g. 10 seconds delay on the fast
    running jobs.
    To find out what exactly happend look fo the output of VSS_REPORTS and
    aask for the run stat's of the jobs mentioned above.
    
    Eric
    

    
    Redefining the logical SYS$INPUT, SYS$OUTPUT, and SYS$COMMAND
    can cause this to happen, too.  Check the login procedures
    and see.
    
    Mark