Jeff,
> there's an invalid comment in the Friday section
That would do it. But there should be an error message in the log file:
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
Looking at your script, here's a few suggestions that may make debugging easier (though, being a programming language, there will be many alternative opinions).
I try to avoid hard coded file specifications. F$PARSE is your friend. If you're talking about the procedure itself, use:
$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
The semi colon is to remove the version number. This will remain correct regardless of where you move the procedure, or even if you rename it.
You can then use "self" to locate related files if they live in the same directory. For example:
$ arc_files=F$PARSE("convert_lockbox_arc_files",self)
$ @'F$PARSE("DISTRIB_MAIL",self)' SYS$SCRATCH:TRANSMITTAL_MSG.TXT
This kind of coding becomes natural, and it makes it trivially easy to move code around, or between systems, as it removes local dependencies.
When dealing with different actions depending on the day of the week, the easiest construct is:
$ GOSUB 'F$CVTIME(,,"WEEKDAY")'
$! Other stuff
$ EXIT
$
$ Monday:
$ Tuesday:
$ Wednesday:
$ Thursday:
$
$ ! Processing for Mon-Thur
$
$ RETURN
$
$ Friday:
$ ! Processing for Fri
$ RETURN
$
$ Saturday:
$ Sunday:
$ RETURN
You could do something similar with "DAY" but that would be rather a lot of labels. Maybe turn it around and use GTS instead of individual tests?
$ IF 'F$CVTIME(,,"DAY").GTS."04"
$ THEN
$ ! stuff to do > 04
$ ENDIF ! Your label end_process
3) Perhaps overkill in this case, but when you have something selectable from a small set, like a day name, a table can sometimes be clearer and easier to maintain than an IF-THEN tree. For example:
$ OnMonday="TOMORROW+2-02:00"
$ OnTuesday=OnMonday
$ OnWednesday=OnMonday
$ OnThursday=OnMonday
$ OnFriday="TOMORROW+02:00"
$ OnSaturday=""
$ OnSunday=""
Now, let the code select itself:
$ after=On'F$CVTIME(,,"WEEKDAY")'
$ IF after.NES."" THEN SUBMIT 'self' /AFTER="''after'" /whatever
This may not be the correct logic for your job, but hopefully you get the idea. You only write one SUBMIT command, and it's very easy to have different times depending on the day. We can also block resubmission on particular days.
That said, rather than try to code the execution schedule in advance by submitting jobs at different intervals, it's often easier to just run the job at the same time every day, and decide if something should be done when it starts to execute. That means it's safe to submit at any time.
I also do my resubmit at the becinning of the job. This helps reduce the risk of something going wrong during the job causing it to abort before the resubmit and breaking the chain. Thus:
$ IF F$MODE().EQS."BATCH" THEN SUBMIT 'self'/AFTER="TOMORROW+02:00"
$
$ ! Work out circumstances, date, day etc...
$ ! maybe use GOTO 'F$CVTIME(,,"WEEKDAY")
$ ! or:
$ IF NothingToDo THEN EXIT
$
$ ! Do stuff
To determine if there's another copy of yourself already scheduled you don't need to scan the whole queue. For the case of jobs owned by yourself DISPLAY_ENTRY is a shortcut. Consider:
$ me=F$GETQUI("DISPLAY_ENTRY","ENTRY_NUMBER",,"THIS_JOB")
$ myname=F$GETQUI("DISPLAY_ENTRY","JOB_NAME",,"THIS_JOB")
$ IF myname.EQS."" THEN myname=F$PARSE(self,,,"NAME")
$ CheckLoop: e=F$GETQUI("DISPLAY_ENTRY","ENTRY_NUMBER",myname,"WILDCARD")
$ IF e.NES."".AND.e.NE.me THEN GOTO CheckLoop
$ IF e.EQS.""
$ THEN
$ ! No matching job scheduled
$ ELSE
$ ! Found job with entry number e
$ ENDIF
Note that this code doesn't hardcode the job name. It also works for interactive mode as "me" will be blank, and we've assumed the job name will be the same as the procedure name.
A crucible of informative mistakes
