Let's have a look at the “Run Job” page in detail.
There are three sections: Parameters, Results and Batch Control.
Parameters differ by job, here we are looking at PurgeMail which presents four rows.
The last two are simply information: links to help you out.
The first is a number of days. Messages older than this many days will be purged.
The second is a drop-down of user groups. Purging will only apply to messages from users in this group.
BEWARE in this first release, the values are not retained, so don't forget to re-select days and groups every time you run.
The results section shows whatever the job has to report.
This job is suitable for both threaded and normal mail, so all the information will not apply to every site. If you don't have threads, you won't see a thread count.
This section is just a quick summary for your information.
|DEBUG||dump batch control and data at start and end of each page/run.|
|INFO||what would happen if bFix was true.|
|NOTICE||what did happen because bFix was true.|
Developers or troubleshooting: use DEBUG LEVEL.
Normally please set this to ERROR. That will give you notices, information and errors only. Which is all you normally want to see.
Set to FALSE to generate the logs only, ad preview what the job will do.
Normally set to true.
CLEAR LOG AT START
If you do not clear the log, it will grow forever. So normally set to YES.
The log is used for development and troubleshooting.
Note more sophisticated possibilities exist, since the log is based on MonoLog and http://tools.ietf.org/html/rfc5424 standards.
RESET BATCH CONTROL
Normally leave this set to TRUE
When set to FALSE, additional fields will open up:
These are for developers and the brave, and they allow you to control exactly where the job begins (start offset) and how many rows to process (stop row). It also exposes the counters. When developing a new job it may be helpful to stop/start, and work with limited/specific rows.
This tells how many rows to process before refreshing the page.
If you set this too high, you will probably get a “timeout” error.
If you set this too low, your job will be spending more time refreshing pages than processing rows.
It is up to you to find a sweet spot. It depends on your server and database power and size.
Err on the high side and go down from there would be my advice. Try it on your dev box first!