submit causing infinite loop

[Jeff Shulmister]

Hi:
I tried coding some dcl to resubmit itself for three days in the future at 2:00 in the morning...the job wound up looping, submitting thousands of jobs to the que...What's the correct way to do this? I had...

submit.../after="tomorrow+2-2:00"

Thanks,

Jeff S

[Steven Schweda]

> submit.../after="tomorrow+2-2:00"

Are you sure that that's what you (or your
procedure) did? Around here, that seems to
work as expected:

alp $ sub harmless.com /after = "tomorrow+2-02:00"
Job harmless (queue SYS$BATCH_ALP, entry 17) holding until 9-APR-2011 02:00

[John McL]

I just checked your time string via lexical f$cvtime()and it returned the time I would expect.

Did you test this from within the self-submitting batch job? Maybe the cause of the looping can be found there.

[John Gillings]

Jeff,

"TOMORROW+2-2:00" seems reasonable to me.

What's the rest of the SUBMIT command?

Do some testing with a minimal job:

RESUBMIT_TEST.COM
$ SET VERIFY
$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
$ WAIT 00:01:00
$ SUBMIT 'self' /whatever you like
$ SHOW ENTRY/FULL '$ENTRY'
$ EXIT

The WAIT should give you time to break a submit loop. Wait for the job to finish, then see if the next one is scheduled as you expect. If it starts immediately, just delete the entry. You can also break a loop with:

$ CREATE RESUBMIT_TEST.COM
$ EXIT
^Z

(because "self" is defined as the latest version of the file, which is always a good idea for a self re-submitting job)

[Hoff]

Are you operating your batch queues in a cluster, and are the system times of the cluster member nodes (badly) skewed?

[The Brit]

Hi Jeff,
In addition to the responses above, can you; 1) add a "set verify" at the start of the job, and then post the section covering the submit, from the batch job logfile. This will give us the complete submit command, and show what response you got from the system when the batch job re-submits itself.

Dave.

[Hein van den Heuvel]

Here is a 'simple' error to cause the /AFTER not to be qualifier and thus the job to re-execute immediately.


$ subm tmp.com/para="test /after=tomorrow
:
$ SHOW ENTRY/FULL ... /PARAM=("test /after=tomorrow")

This still first the definition of your command. So yeah... show us the EXACT command please!

fwiw,
Hein

[Jeff Shulmister]

Well, I wanted to avoid sending this whole script because it's pretty ugly -- but the answer is in here somewhere. The submit is inside a loop, so the first thought is that it's just inside an infinite loop. However, there are two submits -- one that executes Mon thru Thurs, and one for Friday. And only when it does the Friday submit, does it get stuck creating infinite entries in the que.

What's going on in the loop is that it's attempting to see if the job is already in the que. If not, then it will submit the job, and if it is already there, then it won't. At least, that's the intent. Here's the complete DCL...
The loop starts on the Qsearch1 label:

$ set noverify
$ on error then goto write_error
$ setup hprod
$ set def sys$scratch
$ today = f$cvtime(f$time(),,"weekday")
$ day = f$cvtime(f$time(),,"day")
$ show time
$ if day .eqs. "01" .or. day .eqs. "02" .or. day .eqs. "03" .or. day .eqs. "04"
-
then goto end_process
$ quiz auto=star_exe:check_lockbox_purge.qzc
$ show sym purge_okay
$ show sym beg_range
$ show sym end_range
$ if purge_okay .eqs. "N" then goto end_process
$ purge_range == "''beg_range',''end_range'"
$ show sym purge_range
$ qtp auto=star_exe:purge_lockbox_range.qtc
$ submit/noprint/log=star_log/que=sys$batch -
star_com:convert_lockbox_arc_files.com
$ define distrib_name distrib_fm_error
$ @star_com:distrib_mail.com -
"PURGE_LOCKBOX_RANGE.COM completed" -
sys$scratch:TRANSMITTAL_MSG.TXT
$ write sys$output "Purge completed"
$ end_process:
$ show sym today
$ context = f$getqui("CANCEL_OPERATION")
$ qname = f$getqui("DISPLAY_QUEUE","QUEUE_NAME","ERNIE_BATCH","WILDCARD")
$ qsearch_1:
$ jname = -
f$getqui("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS,TIMED_RELEASE_JOBS")
$ if jname .eqs. "PURGE_LOCKBOX_RANGE"
$ then goto eoj
$ endif
$ if jname .eqs. ""
$ then if today .eqs. "Friday" then goto Friday
$ submit/noprint/que=ernie_batch/log=sys$scratch: -
/after="tomorrow+02:00" -
star_root:[com]purge_lockbox_range.com
$ goto eoj
$ Friday:
$ submit/noprint/que=ernie_batch/log=sys$scratch: -
/after="tomorrow+2-02:00" -
star_root:[com]purge_lockbox_range.com
$ goto eoj ; 342394
$ endif
$ goto qsearch_1 ! 342409
$ eoj:
$ type prd$command:[command]success.msg
$ delete TRANSMITTAL_MSG.TXT;*
$ exit
$ write_error:
$ wso " "
$ define distrib_name distrib_fm_error
$ @star_com:distrib_mail.com -
"PURGE_LOCKBOX_RANGE.COM failed, see log for details"
$ type prd$command:[command]failure.msg
$ wso " "
$ exit 2

[abrsvc]

My first suggestion would be to change the label EOJ to something else (End_job maybe). EOJ is a valid DCL command and perhaps the CLI is getting a bit confused. It is a simple change and should be easy to test. Notice that only the "Friday" codeflow is close to that label.

Let us know what happens.

Dan

[Jeff Shulmister]

Hey thanks guys thanks for focusing me on the "eoj" -- I think I actually see the problem!

It looks like there's an invalid comment in the Friday section, on the "goto eoj"... (should have an '!' rather than a ';'.

So, if that line is being ignored, then it will just keep going back to qsearch1!