>Hi Al,
>
>The errors are both kinds..... connection failures, work files not being created to C00005. If I change the code to error handle and exit that error still won't appear in the task scheduler and we're back to base 1 again with a task that didn't finish / failed and we didn't know about it.
>
>Is there some other task scheduling software out there (relatively inexpensive) that will allow you monitor task statuses and report missed and failed tasks ?

Doug pointed you to a good reference that should get you working with the Windows task scheduler and exit codes/errorlevels.

I'm not sure that any other commercial task scheduler would give you any better information. Similar to the Windows task scheduler, they would depend on the tasks themselves giving more detailed information.

If the tasks being run are VFP, it might be a good match to create your own task scheduler using VFP itself. You can use a timer control to run tasks at the proper times. You can record start/stop times, log messages, generate reports, send e-mails to operations staff etc.

If you can modify the VFP tasks that are being run, one thing you can do would be to set a basic flag of some kind, such as:

- make the first thing the task does be to delete a disk file (if present)
- make the last thing it does be to create that file. If the file is not present when the task is supposed to have finished, the task failed

If you run the VFP task via a .CMD/.BAT file, it can test for the presence of the file and act accordingly.

If you can't modify the VFP tasks, maybe you can wrap them in simple VFP wrappers that delete/create a flag file as above.

Hopefully, the VFP tasks already have extensive error handling/ logging / ON ERROR routines in place so you can get a pretty good idea of what went wrong in the case of trappable VFP errors. If you're not familiar with this, you can get the call stack, memvar values, tables in use and detailed information about the error itself. Very helpful for debugging/troubleshooting.

Also, with tasks that are meant to run unattended and reliably, it's a good idea for those tasks to generate text log files and write "success" (or possibly "warning" or "failure") messages to the log at important points.

Bottom line, there are lots of options for tackling this, but the useful ones require some co-operation from the tasks themselves, if you want reliable/detailed information on success or failure of the tasks.

As a sidebar, VFP has a couple of functions that can help with error testing and handling - you can create a test task that purposely errors with one or both of:

- ERROR command to cause a trappable VFP error of your choice
- SYS( 1079 ) to cause a C5 crash (with confirmation); SYS( 1079, 1 ) causes one without confirmation