The following dialog is displayed when you click on the Scheduler menu in the Configurator. This is where you configure, schedule, and monitor jobs. You can also use the other tabs to adjust scheduler settings and behavior as needed.
Here you can also Add, Edit Job Definitions, examine a job's History, or Delete a job. You can also Run jobs on demand, or Stop jobs that are currently running. Job definitions are limited by licensing. Enterprise licenses allow unlimited job definitions while lesser licenses limit job definitions to the allowed instance count of the license.
In the example screenshot above there are four jobs defined. The first is currently running and displayed in blue. It can be manually stopped if needed by selecting the job and then clicking the "Stop" button. The second job, "Test" is unscheduled. Its red background indicates that the last run resulted in an error. By selecting this job and clicking the "History" button, you can see all past runs of this job and view the associated error. The third job, "TransferCSVs" has not been run yet but is currently scheduled to run in the future. Finally, the last job, "USBank", is unscheduled and will only run on demand. You can run a job on demand by selecting it and clicking the "Run" button. If the selected job is currently running, as in the SendPayroll job above, the "Run" button will be become a "Stop" button.
The error status value reflects the final exit value of the script. If you wish to make proper use of this value, it is important that you construct your scripts in such a way that any errors for which you wish to be notified cause termination of the script with an EXIT or top-level RETURN command. Otherwise, if execution of the script halts because there are no more remaining commands to be run, an error status value of "success" is implied. Sometimes it is important to be explicit about a successful run, in which an "EXIT $ERROR_SUCCESS" command will suffice. Consider the following example on how this information can be put together:
FTPLOGON "mysite"
IFERROR GOTO error_handler
FTPCD "/inbox"
IFERROR GOTO error_handler
RCVFILE "*"
IFERROR GOTO error_handler
EXIT $ERROR_SUCCESS ;; exit here with success so we don't accidentally
;; run into the error handler below
:error_handler
EXIT %lasterror
Since service-style scripts that loop continuously are generally designed to never halt, if you wish to obtain an error status value for such scripts, they will need to first be modified to halt using the strategy described above, instead of looping back again to the beginning.
See also: Returning Error Codes from Scripts, EXIT